Comment 15 for bug 1730758

Kathy,

My previous fix was just a wee bit short of complete. The problem is that the asset.cache_copy_visibility() trigger is called before the update has hit the table, and biblio.calculate_bib_visibility_attribute_set() reads the table to get the source value ... which is not yet updated. Doh! However, we /do/ need the trigger to run in BEFORE mode so that it can just adjust the NEW row rather than using UPDATE, or we get an update loop.

So, you will find a new, force-pushed version of the branch which accounts for this. It does so by providing a new version of biblio.calculate_bib_visibility_attribute_set() that can accept the value of NEW.source as an optional parameter, avoiding the read of the (soon-to-be) stale bre row.

The XXXX upgrade script can simply be run again to get the new code in place, and the baseline is updated to match the upgrade script now.

I was seeing the behavior you describe before re-running the upgrade script (always one source behind), and it is properly updating the vis_attr_cache column after re-running it.

Thanks!