Bug 38869

Summary: Keep previous versions of Notices/Slips
Product: Koha Reporter: David Cook <dcook>
Component: NoticesAssignee: Bugs List <koha-bugs>
Status: NEW --- QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: alexander.wagner, lisette, magnus
Version: Main   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11583
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:

Description David Cook 2025-01-13 05:23:29 UTC
It would be very interesting to be keep a version history for Notices/Slips. 

I imagine there must be lots of libraries that curse saving a new version of a Notice/Slip only to realise that they've horribly broken it?

It would be especially useful with bug 11583
Comment 1 Alexander Wagner 2025-01-13 14:46:04 UTC
Sounds like holding the nocites and slips in a `git` would be a nice idea. One could then use the perl-apis to populate the db from there. I implemented a similar procedure for our automatic setup in j2k.
Comment 2 Lisette Scheer 2025-01-13 15:18:48 UTC
Could we update the notices log to use the diff Kyle added and then somehow use that to recreate/rollback?
Comment 3 David Cook 2025-01-13 22:12:59 UTC
(In reply to Alexander Wagner from comment #1)
> Sounds like holding the nocites and slips in a `git` would be a nice idea.
> One could then use the perl-apis to populate the db from there. I
> implemented a similar procedure for our automatic setup in j2k.

I think adding another dependency and moving part might be overkill in this case.
Comment 4 David Cook 2025-01-13 22:15:28 UTC
(In reply to Lisette Scheer from comment #2)
> Could we update the notices log to use the diff Kyle added and then somehow
> use that to recreate/rollback?

I'm not familiar with the diff, but I was pondering a bit about the action_logs.

For each notice, we'd want to quickly and easily be able to see how many revisions there were for a notice. For that, I think we'd need a table in itself. But in theory that table could point to the action_logs.
Comment 5 Alexander Wagner 2025-01-14 07:12:58 UTC
(In reply to David Cook from comment #3)
> (In reply to Alexander Wagner from comment #1)
> > Sounds like holding the nocites and slips in a `git` would be a nice idea.
> > One could then use the perl-apis to populate the db from there. I
> > implemented a similar procedure for our automatic setup in j2k.
> 
> I think adding another dependency and moving part might be overkill in this
> case.

Well, IMHO it would be a very generic dependency (not sure if one even has to `apt get` it manually these days) and allow for a very generic solution generally applicable that might come in handy at various other locations probably some not yet on the radar.

But of course there are other ways to handle diffs.
Comment 6 Katrin Fischer 2025-01-14 13:49:56 UTC
We do have a ReportsLog that is quite nice and could serve as a possible example. The action logs also allow to copare and see diffs. And we can now store JSON diffs as well. I think maybe this could be solved with what we already use in other places.