Missing Permissions in Trunk

[Jason Stephenson]

Evergreen Version: trunk, r19174
PostrgreSLQ Version: 8.4.6
OpenSRF Version: 1.6.2
OS Version: Unbuntu 10.04 Lucid

The permissions in the attachment are missing from trunk, but present in rel_2_0. The lack of some of these causes failures to display org_unit drop down menu content in some screens, specifically Hold and Circulation Policy Configuration.

I created a new bug rather than targeting a new bug because I intend to report a more general issue with missing permissions.

[Jason Stephenson (jstephenson)]

I created a new bug rather than targeting a new bug because I intend to report a more general issue with missing permissions.

Should have been:

I created a new bug rather than targeting an existing bug because I intend to report a more general issue with missing permissions.

You also won't notice these permissions are missing if you use the superuser flag. You'll only notice if you need one of the permissions and don't have superuser, or if you have the EVERYTHING permission. The missing permission causes the query that checks the EVERYTHING permission to fail. (I'll include a patch to fix that.)

[Jason Stephenson (jstephenson)]

The following patch attachment seems to resolve the missing permissions for users who have the EVERYTHING permission at the appropriate depth. It removes the return after a failure to find the missing permission in
permission.usr_has_perm_at_nd() so that those with EVERYTHING will still return the list of ous where they have that permission.

Anyone without super_user or EVERYTHING permission will still fail the permissions check.

[Jason Stephenson (jstephenson)]

Attached is a patch that is half-way to Galen's suggestion in http://libmail.georgialibraries.org/pipermail/open-ils-dev/2011-January/006734.html

It comes out of some discussion in IRC today http://www.open-ils.org/irc_logs/evergreen/2011-01/%23evergreen.18-Tue-2011.log as well as the above email.

This patch retains the id column with the currently fixed values from 2.0, but uses the code for the i18n lookups. From what I can see the database i18n functions (specifically, oils_i18n_gettext) are stubs which do little at this point. So, hopefully, this patch would not cause a headache for translators.

I suppose an upgrade script would be needed, but I'm not sure how that works, exactly.

[Jason Etheridge (phasefx)]

> This patch retains the id column with the currently fixed values from
> 2.0, but uses the code for the i18n lookups. From what I can see the
> database i18n functions (specifically, oils_i18n_gettext) are stubs
> which do little at this point. So, hopefully, this patch would not cause
> a headache for translators.

If I understand correctly, it's external scripts (the I18N build
process) that goes grepping for oils_i18n_gettext and makes use of it,
so though it's a stub function in postgres, how it's used/encoded in
the source is important.

[Jason Stephenson (jstephenson)]

Here's a patch for 950.data.seed-values.sql that simply copies and pastes the permissions from 2.0 into trunk. This changes some of the permission ids in trunk, but they are changed to the value that they have in 2.0, so its likely for the better.

This patch doesn't try to change anything about how the i18n works, so it will still be using the id number to lookup.

[Mike Rylander (mrylander)]

This has been committed to trunk and rel_2_1. Thanks, Jason!