UPDATE_MARC Permission Error in Search Catalog

[Scott Thomas]

One of our logins gets a "Permission Denied UPDATE_MARC" message when trying to access Search the Catalog, but this login has UPDATE_MARC for the entire Consortium. Please attached screen shot. We are at 2.12 on the Web Client.

[Kathy Lussier (klussier)]

I'm unable to reproduce this problem. I logged in with a Concerto Circulator account, which does not have the UPDATE_MARC permission. I didn't get the same message when accessing Search the Catalog.

Scott, can you tell me exactly where this error pops up? Is it as soon as the user clicks "Search the Catalog" or later in the catalog search process? I was wondering if it might pop up when retrieving the record on a workstation where the MARC Edit tab is set as the default.

If the user is able to record a screencast that shows the sequence of steps leading to this message (using something like Jing or Screencastify), it would be very helpful. Thanks!

[Jason Boyer (jboyer)]

I just wanted to chime in that I've seen mention of this also. I can't reliably reproduce it with my account at the moment but I'm trying to track it down also.

[Kathy Lussier (klussier)]

I did find related bug 1693580 while trying to confirm this one.

[Scott Thomas (scott-thomas-9)]

I did some additional testing. I logged into a different workstation (mine) with the problematic user, and the error did not appear. I will ask them to test the problematic workstation again and update this ticket with the results.

[Jason Boyer (jboyer)]

Well, this may help and be vexing at the same time. The easiest way to trigger this is to be to use an incognito window and start fresh. It seems like "something" is saved in a cookie or local storage that prevents this erroneous permissions failure from popping up, but I just wiped out all stored cookies and local storage for a test machine, logged in with what's basically a Circulator account in the seed data, and this error popped right up. Now to find out why...

[Jason Boyer (jboyer)]

Never mind, it wasn't as hard to find as I thought. For some reason creating the Local Storage cached copy of current_tag_table_marc21_biblio is triggering it. You can test this by logging in to the web client as a user without UPDATE_MARC. If you do get the error, override it with a login that has UPDATE_MARC and this local storage key will be added. Then you should be able to click Home and then go back to Adv Search without an error.

Then to verify, also with an account lacking UPDATE_MARC, right click and choose Inspect from the menu (I'm assuming Chrome from here on) and click the Application Tab. Click the disclosure triangle next to Local Storage and click the domain of the machine you're logged into. Then rename the current_tag_table_marc21_biblio to something else. (I couldn't find a way to delete it, only rename it. Oh well.) Then click Home again and then Advanced search. At this point you should receive the permissions failure again.

[Jason Boyer (jboyer)]

And the cause is src/perlmods/lib/OpenILS/Application/Cat.pm line 1657 (rel_2_12) where the retrieve_tag_table function specifically checks for that perm. I doubt it's intentional but I don't know enough to say for sure.

[Galen Charlton (gmc)]

> Then to verify, also with an account lacking UPDATE_MARC, right click
> and choose Inspect from the menu (I'm assuming Chrome from here on) and
> click the Application Tab. Click the disclosure triangle next to Local
> Storage and click the domain of the machine you're logged into. Then
> rename the current_tag_table_marc21_biblio to something else. (I
> couldn't find a way to delete it, only rename it. Oh well.)

As a side note, this can be more easily cleared by going to
/eg/staff/admin/workstation/stored_prefs

[Galen Charlton (gmc)]

On Fri, May 26, 2017 at 9:56 AM, Jason Boyer <email address hidden> wrote:
> And the cause is src/perlmods/lib/OpenILS/Application/Cat.pm line 1657
> (rel_2_12) where the retrieve_tag_table function specifically checks for
> that perm. I doubt it's intentional but I don't know enough to say for
> sure.

There's generally nothing confidential in the MARC tag table, so
removing the permissions check is a possibility - but that masks a
broader issue wherein somebody who doesn't have the right permissions
to save a MARC record probably shouldn't be able to open the MARC
editor (or at least, a read-write version of it).

[Scott Thomas (scott-thomas-9)]

I have some more information on this. The permissions error only appears when using Chrome on a Mac. It does not appear when using Firefox or Chrome on a PC.

[Michele Morgan (mmorgan)]

Confirming this issue on Evergreen 2.12.2, on Windows using Chrome.

- Logged in as a staff user without UPDATE_MARC permission.
- Entered search term "long arm" in the search box on the splash page, click Search.
- Permission denied box appears, followed by search results.

Here's a screencast:

https://www.screencast.com/t/iYqJ5x4VQf

Also, clicking on a title link from places like Item Status also bring up the same message. The message can be cancelled and the record viewed. Screencast at:

https://www.screencast.com/t/UogKFNeWwI

Note that when using a Chrome browser where the superuser had previously performed searches in the staff client, the permission error did not appear. Opening an incognito window and logging in with the lower level user successfully reproduced the permission error.

[Kathy Lussier (klussier)]

This branch in the working repo removes the permission check, allowing staff users without the required permission to perform searches in the staff catalog:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/lp1693560-remove-permission-check-for-retrieve-tag-table

Would it be acceptable to address the issue with the MARC editor in related bug 1693580? In my previous testing, I found that if a user without the UPDATE_MARC permission did not encounter the problem with the search (because a superuser had previously logged in?), we were already seeing a problem where they were able to use the MARC Editor without the correct permission.

[Galen Charlton (gmc)]

The PCRUD permissions for the underlying tables allow any logged-in user to access the tag tables, so I'm inclined to run with this patch. I'll test it now.

[Galen Charlton (gmc)]

Pushed to master, and rel_2_12. Thanks, Kathy!