Bug 17998 - Notice ISSUEQSLIP changes do not take effect consistently
Summary: Notice ISSUEQSLIP changes do not take effect consistently
Status: CLOSED WORKSFORME
Alias: None
Product: Koha
Classification: Unclassified
Component: Notices (show other bugs)
Version: 3.22
Hardware: All All
: P5 - low minor (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-01-25 22:54 UTC by Agnes Rivers-Moore
Modified: 2018-06-04 20:10 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:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Agnes Rivers-Moore 2017-01-25 22:54:10 UTC
Changes made the the ISSUEQSLIP template text may eventually happen but not quickly. When the slip is printed, for some time older versions appear instead.
This might not happen in later versions, tested in 3.22.
We have not tested this in any other notice templates - only ISSUEQSLIP.
Details:
I make a change (in the 'email' tab), submit, and then open another tab to view or print the change in patron checkout, and my changes are not there.
After making several changes to the layout in the 'email' tab, and then attempting to print the slip - newest changes are not there in the print for some time and the preceding versions continue to appear - not the same older version every time but alternating different versions.
I did this all in both our 'sandbox' test system, and in our live system. Eventually got the layout I wanted in the test system and copied it to the live system, but still changes did not happen once submitted.
I also created a Hanover Library rule (as opposed to the 'all libraries' one), and that seemed to make things worse. I have deleted it.
I tried closing browser, using a different browser... and still I would get the version before last or the one before that instead of the most recently submitted.
I tried submitting, closing the edit page, waiting, opening and submitting again three times.

John at Equinox tested the issue and reported that:
I was able to duplicate the issue you described, although this is the first I've heard of it.

Some things I found while examining this:
1) the changes do register immediately in the database where the templates are stored.
2) In my testing, every other time I printed a quick slip it would reflect the change, until eventually it would show the change every time.
3) Different browsers made no difference.
4) Restarting Apache between changes appeared to make no difference either.
5) I was not able to duplicate it on 16.05 system
It does seem like this is a bug.

Katrin asked whether we are using Plack (yes) and caching (I don't know), and she asked that we submit a new bug for this.

If anyone could test it on your local 16.05 setup and report whether this can be duplicated, or comment on whether it is related to Plack or caching setup that would be great. 
We will hope that it is gone in the next release but provide this information for anyone who might run into it or in case it indicates a larger underlying issue.
Comment 1 Katrin Fischer 2017-08-17 11:23:22 UTC
Hi Agnes, I think it's Plack that is causing this. In 3.22 we have it happen often that system preference changes don't take effect immediately, but only after many reloads of the page or a restart of Plack. 
I think this should be resolved in versions from 16.05, but we have just started testing 16.11.
Comment 2 Liz Rea 2017-10-08 22:05:09 UTC
This is very likely caused by Plack.