After further testing, it seems the problem relates to the number of work locations I assigned. I was assigning every branch library (170 locations in our instance) to each of the network staff. When I only assigned one branch location, then the org units display properly.
It seems to me that network staff should be ok with just one work ou if their permissions are set at the consortium level. Is there a reason to give network staff every work location? Thanks, Tim On Mon, Mar 21, 2011 at 11:42 AM, Tim Spindler <tjspind...@gmail.com> wrote: > That seems to be the problem but there is a twist. In setting up the user > accounts I ran the following SQL statment to automatically assign all of our > branch locations to network staff. > > insert into "permission"."usr_work_ou_map" (usr, work_ou) SELECT 15, id > FROM actor.org_unit WHERE ou_type=4 > > When I set up an account manually through the client it was working. > > Tim > > > On Mon, Mar 21, 2011 at 11:11 AM, Ben Shum <bs...@biblio.org> wrote: > >> Aha, that sounds correct. >> >> Have you checked to make sure that you've granted working locations for >> the network staff accounts for the workstations they're logging in from? >> >> -- Ben >> >> >> On 03/21/2011 11:05 AM, Tim Spindler wrote: >> >> Thanks Ben, I'm confused then because I have >> >> >> - group_application.user >> - group_application.user.patron >> >> At the STAFF level and I assumed that it would cascade down for the >> groups underneath staff (ACADEMIC, PUBLIC, and NETWORK). I don't have >> anything additional on the public staff and they are able to register >> patrons without the org unit problem. >> >> Tim >> >> On Mon, Mar 21, 2011 at 10:58 AM, Ben Shum <bs...@biblio.org> wrote: >> >>> Hi Tim, >>> >>> Looking at the permissions, I think you have to add one for the network >>> staff for general all users: group_application.user >>> >>> If they don't have that, they won't be able to create any user who's a >>> child of the primary users group (i.e. every other group). >>> >>> Probably also need to have group_application.user.patron (since I see you >>> have at least one of those) and any other parent group above them. >>> >>> -- Ben >>> >>> >>> On 03/21/2011 10:53 AM, Tim Spindler wrote: >>> >>> I'm not sure if this is a bug or the way I have something set up but I'm >>> looking for Advice. I have a situation where public library staff can >>> register patrons and the local admin can set up accounts for their library >>> fine. Howver, none of the network staff can create user accounts because the >>> org unit drop down will not populate the org units. However, when logged in >>> as a public library staff member it all works fine. But network staff >>> can't do anything. We are on a test install of v.2.03. First we have the >>> following permission group >>> >>> >>> - Users >>> - Patrons >>> - Staff >>> - Academics >>> - Network >>> - Network Administrator (has "Everything" permission and >>> still cannot register a patron due to the org unit drop down) >>> - Technical Services Staff >>> - Support staff >>> - Publics >>> >>> The following are the specific permissions for each permission group >>> >>> Staff >>> >>> - CHECKIN_BYPASS_HOLD_FULFILL >>> - COPY_CHECKOUT >>> - COPY_HOLDS >>> - COPY_TRANSIT_RECEIVE >>> - CREATE_BILL >>> - CREATE_CONTAINER >>> - CREATE_CONTAINER_ITEM >>> - CREATE_COPY_NOTE >>> - CREATE_COPY_TRANSIT >>> - CREATE_HOLD_NOTIFICATION >>> - CREATE_IN_HOUSE_USE >>> - CREATE_NON_CAT_TYPE >>> - CREATE_PAYMENT >>> - CREATE_TRANSACTION >>> - CREATE_TRANSIT >>> - CREATE_USER >>> - CREATE_VOLUME_NOTE >>> - DELETE_CONTAINER >>> - DELETE_USER >>> - OFFLINE_UPLOAD >>> - OFFLINE_VIEW >>> - RENEW_CIRC >>> - RENEW_HOLD_OVERRIDE >>> - REQUEST_HOLDS >>> - SET_CIRC_CLAIMS_RETURNED >>> - SET_CIRC_LOST >>> - SET_CIRC_MISSING >>> - STAFF_LOGIN >>> - UPDATE_BATCH_COPY >>> - UPDATE_CONTAINER >>> - UPDATE_NON_CAT_TYPE >>> - UPDATE_ORG_SETTING >>> - UPDATE_ORG_UNIT >>> - UPDATE_USER >>> - VIEW_BILLING_TYPE >>> - VIEW_CIRCULATIONS >>> - VIEW_CONTAINER >>> - VIEW_COPY_CHECKOUT_HISTORY >>> - VIEW_COPY_NOTES >>> - VIEW_HOLD >>> - VIEW_HOLD_NOTIFICATION >>> - VIEW_HOLD_PERMIT >>> - VIEW_ORG_SETTINGS >>> - VIEW_PERMISSION >>> - VIEW_PERMIT_CHECKOUT >>> - VIEW_PERM_GROUPS >>> - VIEW_TITLE_NOTES >>> - VIEW_TRANSACTION >>> - VIEW_USER >>> - VIEW_USER_FINES_SUMMARY >>> - VIEW_USER_TRANSACTIONS >>> - VIEW_VOLUME_NOTES >>> - VOLUME_HOLDS >>> - group_application.user >>> - group_application.user.patron >>> - group_application.user.patron.publics >>> >>> Public >>> >>> No additional permissions at this level >>> >>> Academic >>> >>> - group_application.user.patron.academics >>> >>> Network >>> >>> - >>> - group_application.user.patron.academics >>> - group_application.user.staff >>> - group_application.user.staff.academic >>> - group_application.user.staff.admin.lib_manager >>> - group_application.user.staff.admin.local_admin >>> - group_application.user.staff.admin.mini >>> - group_application.user.staff.ola >>> - group_application.user.staff.public >>> >>> >>> -- >>> >>> ____________________________ >>> >>> Tim Spindler >>> >>> Manager of Library Applications >>> >>> tspind...@cwmars.org >>> >>> C/W MARS, Inc. >>> >>> http://www.cwmars.org >>> >>> >>> -- >>> Benjamin Shum >>> Open Source Software Coordinator >>> Bibliomation, Inc. >>> 32 Crest Road >>> Middlebury, CT 06762203-577-4070, ext. 113 >>> >>> >> >> >> -- >> __________________________ >> Tim Spindler >> tjspind...@gmail.com >> >> >> -- >> Benjamin Shum >> Open Source Software Coordinator >> Bibliomation, Inc. >> 32 Crest Road >> Middlebury, CT 06762203-577-4070, ext. 113 >> >> > > > -- > __________________________ > Tim Spindler > tjspind...@gmail.com > -- __________________________ Tim Spindler tjspind...@gmail.com