Re: [OPEN-ILS-GENERAL] Problem with update_volume permissions
Michelle, Thanks for that, but no. We are always using the Main permission group. Because of the bug, we have tried to stay away from the secondary groups completely. Jennifer From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Morgan, Michele Sent: Monday, April 24, 2017 4:44 PM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] Problem with update_volume permissions Jennifer, Are you assigning a Secondary Permission Group to the user? Or are you editing the Main (Profile) Permission Group? If it's a secondary, you may be running into this bug: https://bugs.launchpad.net/evergreen/+bug/1480432 If this is your issue, you can try setting your new permission group as the user's main profile. Hope this is helpful, Michele -- Michele M. Morgan, Technical Support Analyst North of Boston Library Exchange, Danvers Massachusetts mmor...@noblenet.org<mailto:mmor...@noblenet.org> On Mon, Apr 24, 2017 at 4:26 PM, Walz, Jennifer mailto:jlw...@asbury.edu>> wrote: Chris, Thanks for that information. Currently we have the permission groups set up in a pretty flat tree: Staff -ACQ -Cat -Circ -Cat admin -Circ admin -Tech workers -ILL -Etc There are no further levels. I was trying to create another one on the same level as the two Acq and Cat, but combined. So, I was not going down another level. And it looks to me like maybe they were ALL inheriting something from the staff level. So, I will check that first. But regardless of whatever is set at the cat, acq, tech workers, etc level, every single one of those users has the individual user permission set lower still. Here is what I am seeing. At the permission group editor – in the group permissions tab – I set the “update_volume” to the consortium level. But when I go to the user account that has been assigned to that permission group, their individual user permission for “update_volume” is at the branch. And I cannot change it or remove it at the user level. It remains always at the branch. I will look into the server permissions table. Could be something is corrupted there. Thanks! Jennifer From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org<mailto:open-ils-general-boun...@list.georgialibraries.org>] On Behalf Of Chris Sharp Sent: Monday, April 24, 2017 4:14 PM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] Problem with update_volume permissions Jennifer, Permissions are inherited. Here's a sample permissions tree: Staff - Catalogers - AcqCataloger - (individual user with the 'AcqCataloger' profile) Permissions can get assigned at any level in the tree, but if the permission is assigned at more than one level, the "lower down the tree" (towards the individual user) assignments override those assigned "higher up the tree" (towards "Staff"). For example, it sounds like the users being "downgraded" have the UPDATE_VOLUME permission assigned to them at the individual user level at a depth that is too low. Since it's impossible to tell from the User Permission Editor interface what's what, you might need the assistance of systems staff with database access to do some cleanup. The relevant table for user-assigned permissions is permission.usr_perm_map. By the way, in PINES we have tried to get away from assigning too many permissions at the individual user level, and the situation you're in is one of the reasons. I'll also share a tool we have that will show a profiles combined permissions (again, someone with database access would need to run it): http://git.evergreen-ils.org/?p=contrib/pines.git;a=blob;f=helper-scripts/get_combined_perms_per_profile.sh;h=0c0b5f80c01fe417638cde2a02cb799f7c71fb46;hb=HEAD Once the script is created, it can be evoked with the permission group's name (e.g. "./get_combined_perms_per_profile AcqCataloger" to use the above example). That might help you sort things out. Hope that's helpful! Chris On Mon, Apr 24, 2017 at 2:51 PM, Walz, Jennifer mailto:jlw...@asbury.edu>> wrote: All – We have set up a new permission group where we would like to combine the functions / permissions of the acquisitions and cataloging all into one. So, I created a new permissions group, and added all the permissions to that new group that looked like it dealt with both acq and cat functions. Then I assigned a new staff patron login to that permission group. Here is where we are running into a problem. NO MATTER what depth I have assigned at the permission group level for the ‘update_volume’ permission, it keeps getting ‘downgraded’ to the lowest depth at the user permission level. What is going on? What am I missing? This new staff pe
Re: [OPEN-ILS-GENERAL] Problem with update_volume permissions
Chris – et al – Aha! I think this has happened before and I don’t know why it keeps showing up. The “staff” level was assigned a lower depth. Grief! Now I’ve got a bead on it and we are going to straighten this one out. ☺ Thanks for your help! Jennifer From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Chris Sharp Sent: Monday, April 24, 2017 4:14 PM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] Problem with update_volume permissions Jennifer, Permissions are inherited. Here's a sample permissions tree: Staff - Catalogers - AcqCataloger - (individual user with the 'AcqCataloger' profile) Permissions can get assigned at any level in the tree, but if the permission is assigned at more than one level, the "lower down the tree" (towards the individual user) assignments override those assigned "higher up the tree" (towards "Staff"). For example, it sounds like the users being "downgraded" have the UPDATE_VOLUME permission assigned to them at the individual user level at a depth that is too low. Since it's impossible to tell from the User Permission Editor interface what's what, you might need the assistance of systems staff with database access to do some cleanup. The relevant table for user-assigned permissions is permission.usr_perm_map. By the way, in PINES we have tried to get away from assigning too many permissions at the individual user level, and the situation you're in is one of the reasons. I'll also share a tool we have that will show a profiles combined permissions (again, someone with database access would need to run it): http://git.evergreen-ils.org/?p=contrib/pines.git;a=blob;f=helper-scripts/get_combined_perms_per_profile.sh;h=0c0b5f80c01fe417638cde2a02cb799f7c71fb46;hb=HEAD Once the script is created, it can be evoked with the permission group's name (e.g. "./get_combined_perms_per_profile AcqCataloger" to use the above example). That might help you sort things out. Hope that's helpful! Chris On Mon, Apr 24, 2017 at 2:51 PM, Walz, Jennifer mailto:jlw...@asbury.edu>> wrote: All – We have set up a new permission group where we would like to combine the functions / permissions of the acquisitions and cataloging all into one. So, I created a new permissions group, and added all the permissions to that new group that looked like it dealt with both acq and cat functions. Then I assigned a new staff patron login to that permission group. Here is where we are running into a problem. NO MATTER what depth I have assigned at the permission group level for the ‘update_volume’ permission, it keeps getting ‘downgraded’ to the lowest depth at the user permission level. What is going on? What am I missing? This new staff person cannot make changes beyond the branch depth. Why? What other factors affect the ‘update_volume’ permissions? Are there some other permissions that work in tandem? BTW, I have already authorized this patron account to have working locations for the OU across the consortium / system / library depths. Thanks! Jennifer -- Jennifer Walz, MLS - Head of ILS permissions Kinlaw Library - Asbury University 1 Macklem Drive, Wilmore, KY 40390 859-858-3511 ext. 2269 jlw...@asbury.edu<mailto:jlw...@asbury.edu> -- Chris Sharp PINES System Administrator Georgia Public Library Service 1800 Century Place, Suite 150 Atlanta, Georgia 30345 (404) 235-7147
Re: [OPEN-ILS-GENERAL] Problem with update_volume permissions
Jennifer, Are you assigning a *Secondary Permission Group* to the user? Or are you editing the *Main (Profile) Permission Group*? If it's a secondary, you may be running into this bug: https://bugs.launchpad.net/evergreen/+bug/1480432 If this is your issue, you can try setting your new permission group as the user's main profile. Hope this is helpful, Michele -- Michele M. Morgan, Technical Support Analyst North of Boston Library Exchange, Danvers Massachusetts mmor...@noblenet.org On Mon, Apr 24, 2017 at 4:26 PM, Walz, Jennifer wrote: > Chris, > > > > Thanks for that information. Currently we have the permission groups set > up in a pretty flat tree: > > > > Staff > > -ACQ > > -Cat > > -Circ > > -Cat admin > > -Circ admin > > -Tech workers > > -ILL > > -Etc > > > > There are no further levels. > > > >I was trying to create another one on the same level as the two Acq and > Cat, but combined. So, I was not going down another level. > > > > And it looks to me like maybe they were ALL inheriting something from > the staff level. So, I will check that first. But regardless of whatever > is set at the cat, acq, tech workers, etc level, every single one of those > users has the individual user permission set lower still. > > > > Here is what I am seeing. At the permission group editor – in the group > permissions tab – I set the “update_volume” to the consortium level. But > when I go to the user account that has been assigned to that permission > group, their individual user permission for “update_volume” is at the > branch. And I cannot change it or remove it at the user level. It > remains always at the branch. > > > > I will look into the server permissions table. Could be something is > corrupted there. > > > > Thanks! > > > > Jennifer > > > > *From:* Open-ils-general [mailto:open-ils-general- > boun...@list.georgialibraries.org] *On Behalf Of *Chris Sharp > *Sent:* Monday, April 24, 2017 4:14 PM > *To:* Evergreen Discussion Group > *Subject:* Re: [OPEN-ILS-GENERAL] Problem with update_volume permissions > > > > Jennifer, > > Permissions are inherited. Here's a sample permissions tree: > > Staff > > - Catalogers > > - AcqCataloger > >- (individual user with the 'AcqCataloger' profile) > > Permissions can get assigned at any level in the tree, but if the > permission is assigned at more than one level, the "lower down the tree" > (towards the individual user) assignments override those assigned "higher > up the tree" (towards "Staff"). For example, it sounds like the users > being "downgraded" have the UPDATE_VOLUME permission assigned to them at > the individual user level at a depth that is too low. Since it's > impossible to tell from the User Permission Editor interface what's what, > you might need the assistance of systems staff with database access to do > some cleanup. The relevant table for user-assigned permissions is > permission.usr_perm_map. > > By the way, in PINES we have tried to get away from assigning too many > permissions at the individual user level, and the situation you're in is > one of the reasons. > > I'll also share a tool we have that will show a profiles combined > permissions (again, someone with database access would need to run it): > http://git.evergreen-ils.org/?p=contrib/pines.git;a=blob;f= > helper-scripts/get_combined_perms_per_profile.sh;h= > 0c0b5f80c01fe417638cde2a02cb799f7c71fb46;hb=HEAD > > Once the script is created, it can be evoked with the permission group's > name (e.g. "./get_combined_perms_per_profile AcqCataloger" to use the > above example). That might help you sort things out. > > Hope that's helpful! > > Chris > > > > On Mon, Apr 24, 2017 at 2:51 PM, Walz, Jennifer wrote: > > All – > > > > We have set up a new permission group where we would like to combine the > functions / permissions of the acquisitions and cataloging all into one. > So, I created a new permissions group, and added all the permissions to > that new group that looked like it dealt with both acq and cat functions. > Then I assigned a new staff patron login to that permission group. > > > > Here is where we are running into a problem. NO MATTER what depth I have > assigned at the permission group level for the ‘update_volume’ permission, > it keeps getting ‘downgraded’ to the lowest depth at the user permission > level. What is going on? Wha
Re: [OPEN-ILS-GENERAL] Problem with update_volume permissions
Chris, Thanks for that information. Currently we have the permission groups set up in a pretty flat tree: Staff -ACQ -Cat -Circ -Cat admin -Circ admin -Tech workers -ILL -Etc There are no further levels. I was trying to create another one on the same level as the two Acq and Cat, but combined. So, I was not going down another level. And it looks to me like maybe they were ALL inheriting something from the staff level. So, I will check that first. But regardless of whatever is set at the cat, acq, tech workers, etc level, every single one of those users has the individual user permission set lower still. Here is what I am seeing. At the permission group editor – in the group permissions tab – I set the “update_volume” to the consortium level. But when I go to the user account that has been assigned to that permission group, their individual user permission for “update_volume” is at the branch. And I cannot change it or remove it at the user level. It remains always at the branch. I will look into the server permissions table. Could be something is corrupted there. Thanks! Jennifer From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Chris Sharp Sent: Monday, April 24, 2017 4:14 PM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] Problem with update_volume permissions Jennifer, Permissions are inherited. Here's a sample permissions tree: Staff - Catalogers - AcqCataloger - (individual user with the 'AcqCataloger' profile) Permissions can get assigned at any level in the tree, but if the permission is assigned at more than one level, the "lower down the tree" (towards the individual user) assignments override those assigned "higher up the tree" (towards "Staff"). For example, it sounds like the users being "downgraded" have the UPDATE_VOLUME permission assigned to them at the individual user level at a depth that is too low. Since it's impossible to tell from the User Permission Editor interface what's what, you might need the assistance of systems staff with database access to do some cleanup. The relevant table for user-assigned permissions is permission.usr_perm_map. By the way, in PINES we have tried to get away from assigning too many permissions at the individual user level, and the situation you're in is one of the reasons. I'll also share a tool we have that will show a profiles combined permissions (again, someone with database access would need to run it): http://git.evergreen-ils.org/?p=contrib/pines.git;a=blob;f=helper-scripts/get_combined_perms_per_profile.sh;h=0c0b5f80c01fe417638cde2a02cb799f7c71fb46;hb=HEAD Once the script is created, it can be evoked with the permission group's name (e.g. "./get_combined_perms_per_profile AcqCataloger" to use the above example). That might help you sort things out. Hope that's helpful! Chris On Mon, Apr 24, 2017 at 2:51 PM, Walz, Jennifer mailto:jlw...@asbury.edu>> wrote: All – We have set up a new permission group where we would like to combine the functions / permissions of the acquisitions and cataloging all into one. So, I created a new permissions group, and added all the permissions to that new group that looked like it dealt with both acq and cat functions. Then I assigned a new staff patron login to that permission group. Here is where we are running into a problem. NO MATTER what depth I have assigned at the permission group level for the ‘update_volume’ permission, it keeps getting ‘downgraded’ to the lowest depth at the user permission level. What is going on? What am I missing? This new staff person cannot make changes beyond the branch depth. Why? What other factors affect the ‘update_volume’ permissions? Are there some other permissions that work in tandem? BTW, I have already authorized this patron account to have working locations for the OU across the consortium / system / library depths. Thanks! Jennifer -- Jennifer Walz, MLS - Head of ILS permissions Kinlaw Library - Asbury University 1 Macklem Drive, Wilmore, KY 40390 859-858-3511 ext. 2269 jlw...@asbury.edu<mailto:jlw...@asbury.edu> -- Chris Sharp PINES System Administrator Georgia Public Library Service 1800 Century Place, Suite 150 Atlanta, Georgia 30345 (404) 235-7147
Re: [OPEN-ILS-GENERAL] Problem with update_volume permissions
Jennifer, Permissions are inherited. Here's a sample permissions tree: Staff - Catalogers - AcqCataloger - (individual user with the 'AcqCataloger' profile) Permissions can get assigned at any level in the tree, but if the permission is assigned at more than one level, the "lower down the tree" (towards the individual user) assignments override those assigned "higher up the tree" (towards "Staff"). For example, it sounds like the users being "downgraded" have the UPDATE_VOLUME permission assigned to them at the individual user level at a depth that is too low. Since it's impossible to tell from the User Permission Editor interface what's what, you might need the assistance of systems staff with database access to do some cleanup. The relevant table for user-assigned permissions is permission.usr_perm_map. By the way, in PINES we have tried to get away from assigning too many permissions at the individual user level, and the situation you're in is one of the reasons. I'll also share a tool we have that will show a profiles combined permissions (again, someone with database access would need to run it): http://git.evergreen-ils.org/?p=contrib/pines.git;a=blob;f=helper-scripts/get_combined_perms_per_profile.sh;h=0c0b5f80c01fe417638cde2a02cb799f7c71fb46;hb=HEAD Once the script is created, it can be evoked with the permission group's name (e.g. "./get_combined_perms_per_profile AcqCataloger" to use the above example). That might help you sort things out. Hope that's helpful! Chris On Mon, Apr 24, 2017 at 2:51 PM, Walz, Jennifer wrote: > All – > > > > We have set up a new permission group where we would like to combine the > functions / permissions of the acquisitions and cataloging all into one. > So, I created a new permissions group, and added all the permissions to > that new group that looked like it dealt with both acq and cat functions. > Then I assigned a new staff patron login to that permission group. > > > > Here is where we are running into a problem. NO MATTER what depth I have > assigned at the permission group level for the ‘update_volume’ permission, > it keeps getting ‘downgraded’ to the lowest depth at the user permission > level. What is going on? What am I missing? This new staff person > cannot make changes beyond the branch depth. Why? > > > > What other factors affect the ‘update_volume’ permissions? Are there > some other permissions that work in tandem? > > > > BTW, I have already authorized this patron account to have working > locations for the OU across the consortium / system / library depths. > > > > Thanks! > > > > Jennifer > > -- > Jennifer Walz, MLS - Head of ILS permissions > Kinlaw Library - Asbury University > 1 Macklem Drive, Wilmore, KY 40390 > 859-858-3511 ext. 2269 <(859)%20858-3511> > jlw...@asbury.edu > > > -- Chris Sharp PINES System Administrator Georgia Public Library Service 1800 Century Place, Suite 150 Atlanta, Georgia 30345 (404) 235-7147
