Bug 38869 - Keep previous versions of Notices/Slips
Summary: Keep previous versions of Notices/Slips
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Notices (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-01-13 05:23 UTC by David Cook
Modified: 2025-01-14 13:49 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.