Evergreen

Added content cache can't be cleared in angular

Bug #1939162 reported by Elaine Hardy
100
This bug affects 21 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Medium
Unassigned
Evergreen 3.12.2
3.11
Fix Released
Medium
Unassigned
Evergreen 3.11.4

Bug Description

With the change to the static patron view, and the solution to that - https://bugs.launchpad.net/evergreen/+bug/1910452, there is currently no way in the angular catalog to clear the added content cache.

Correcting the added content often requires clearing the cache. Prior to angular, there was a button in the OPAC view in the staff client that cleared the cache. Since that embedded OPAC view is no longer in the staff client, there is no way within angular to clear the cache

Revision history for this message
Elaine Hardy (ehardy) wrote :
Jennifer Weston (jweston)
Changed in evergreen:
status: New → Confirmed
Jennifer Weston (jweston)
tags: added: staffcatalog
Revision history for this message
Jennifer Weston (jweston) wrote (last edit ):

Discussed in Cat IG. Confirming this functionality is not available in angular staff catalog (testing in 3.7) and is missed for the purpose of seeing the effect of changes made in a timely manner. Use case: refreshing cover images. Logging out and back in does not consistently clear cache to confirm changes; neither does a hard refresh of the screen.

Workaround now is to make changes and go to public catalog to see if changes take effect.

The refresh of content in the staff client is often not fully reflected for 24 hours or more without the ability to clear added content cache at the time changes are made.

Terran McCanna (tmccanna)
tags: added: regression
Stephanie Leary (stephanieleary)
tags: added: usability
Revision history for this message
Jennifer Weston (jweston) wrote :

(Discussed in Cataloging IG meeting on Oct 11, 2022) -- Another workaround is to continue to use the Traditional Search as long as it is available

tags: added: staffcatalogblocker
Revision history for this message
Galen Charlton (gmc) wrote :

A patch to restore this action is available in the working/user/gmcharlt/lp1939162_add_ac_clear_cache / https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/gmcharlt/lp1939162_add_ac_clear_cache branch

tags: added: pullrequest
Changed in evergreen:
importance: Undecided → Medium
Revision history for this message
Jason Boyer (jboyer) wrote :

During testing I found that if you haven't caused the 'ses' cookie to be set the clear cache action will be redirected to the login page. This also returns a 200 and is seen as successful, even though nothing is done. It looks like WWW/AccessHandler.pm might be one of the last places we're not considering both possible cookie names.

Here's a branch that signs off on Galen's commit and adds another to use the newer cookie: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jboyer/lp1939162_clear_cache_signoff / working/user/jboyer/lp1939162_clear_cache_signoff

Revision history for this message
Galen Charlton (gmc) wrote :

I've tested and signed off on Jason's follow-up (thanks!). Current signoff branch is now working/user/gmcharlt/lp1939162_signoff

tags: added: signedoff
Revision history for this message
Galen Charlton (gmc) wrote :

As over two weeks have passed, merging this to main, rel_3_12, and rel_3_11.

Changed in evergreen:
milestone: none → 3.12.2
status: Confirmed → Fix Committed
Ruth Frasur Davis (redavis)
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.