Acquisitions - Unable to view providers

Bug #731510 reported by Tim Spindler
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evergreen
Status tracked in Main
2.0
Fix Released
Undecided
Unassigned
2.1
Fix Released
Undecided
Unassigned
Main
Fix Released
Medium
Mike Rylander

Bug Description

On Evergreen 2.0.1, cannot view providers on Server Administration menu except with the permission Everything or Super User. I removed all permissions and then gave every permission except the "Everything" permission but still cannot see Providers in server administrations. Providers will come up when creating a purchase order.

Revision history for this message
Tim Spindler (tspindler-cwmars) wrote :

I was just able to check with an installation of trunk (Jason Stephensons demo server) and the issue does not appear. We are runninig 2.0.3 currently at C/W MARS where I'm seeing the problem. The user has the permission "ADMIN PROVIDER"

Revision history for this message
Tim Spindler (tspindler-cwmars) wrote :

I was just testing this and ran into this again with our 2.1 installation. I'm not sure if the permission is supposed to work this way but when the permission to admin_providers is given at the consortium level, all providers can be viewed. When given at the system level, none are viewable. This is all in the providers list at admin>>servers>>acquisitions>>providers. There is no problem viewing providers from a PO or other areas when the permission is set to admin_providers at the town level.

I am just not sure if this is a bug or the way it is designed to function.

Revision history for this message
Jason Stephenson (jstephenson) wrote :

First part sounds like the missing permissions bug, which was resolved.

I can't comment on the second part (Comment #2) since I don't look at or use Acquisitions.

Could someone with more experience in Acquisitions take a look?

Revision history for this message
Tim Spindler (tspindler-cwmars) wrote :

I'm still having issues. Christine Morgan tested this without problems at Noble however I think someone should test to see if the permission allows one to see providers if it is set to a level more than 2 levels below the top level level. (using v2.1 b1)

In our setup, we have org units set up as follows:

Consortium
Region
Town (system)
Library/Branch

I then tested it to see what the login could see if the permission was set for consortium vs. region vs. system vs. branch. Under branch and system I had the same problem with no providers showing but for region and consortium I could see providers but it did not seem to recognize the permission for anything below the send level. The region appeared to also drop some of the providers but I have been unable to determine what would be unique about the providers it drops.

Revision history for this message
Ben Shum (bshum) wrote :

This seems to affect our installation of 2.0.6 as well.

In our case, our consortium is constructed with a three-tier structure:

Consortium
System Branch
Specific Library

Our permissions are set for "Library", and we encounter a viewing problem for providers if the library user we're using isn't listed on the "first page of results" (15 results). The page generates blank, but if you click the "Next" button, and page through empty pages, you will eventually reach a page that does show providers for the specific library in question. This is less troublesome for libraries that start higher in the alphabet I guess.

Presumably this means to me that the permissions are being respected by the interface, but the interface isn't rendering the information meaningfully to the Acquisitions end-user. Looking to the /openils/var/web/templates/default/conify/global/acq/provider.tt2 to see if I can glean any hints for how the page is generated.

Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
summary: - Acquisitions Permission
+ Acquisitions - Unable to view providers
tags: added: 2.0 acq
Revision history for this message
Tim Spindler (tspindler-cwmars) wrote :

I just tested what Ben is talking about and can confirm that our system (version 2.1 beta) is performing the same way. I did not see this before but if I click next I do eventually see the providers.

James Fournie (jfournie)
Changed in evergreen:
assignee: nobody → James Fournie (jfournie)
Revision history for this message
James Fournie (jfournie) wrote :

I've created a fix which adds an org unit selector to the providers screen and in the process seems to resolve the problem, however wider testing would be appreciated.

working/user/jamesrf/lp731510_providers_admin

The branch is trunk, but the patch is 0e0b303015d650039eaf1fa95cea1e5de8359e4d and easily cherry-picks onto 2.0 (and presumably 2.1)

Revision history for this message
James Fournie (jfournie) wrote :

I should add my patch expects you to have the VIEW_PROVIDER permission

tags: added: pullrequest
Changed in evergreen:
assignee: James Fournie (jfournie) → nobody
Revision history for this message
Ben Shum (bshum) wrote :

Neat patch, I just applied it to one of our 2.0 test servers and things seem to be going well. I can confirm that having the context org unit set to the library specific will now hide all the others (unless there are system or consortium level providers viewable by all, which is good) and keeps things from looking too strangely.

One observation though, I have an extra scrollbar over the context org unit that moves the box area for Provider and the two buttons (New Provider, Delete Selected). Might be something I did wrong when hand patching the changes, or a quirk due to the resolution on my laptop screen perhaps.

Otherwise, looking good, thanks James!

Changed in evergreen:
status: Confirmed → In Progress
Changed in evergreen:
assignee: nobody → Mike Rylander (mrylander)
Revision history for this message
Mike Rylander (mrylander) wrote :

Pulled into master, 2.1 and 2.0. Thanks, James!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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