Bug 2426 - Management permissions is deprecated
Summary: Management permissions is deprecated
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: Main
Hardware: PC All
: P3 normal (vote)
Assignee: Katrin Fischer
QA Contact: Marcel de Rooy
URL:
Keywords:
: 11776 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-07-30 07:50 UTC by Nicole C. Engard
Modified: 2019-10-14 19:58 UTC (History)
7 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 2426: Remove deprecated management permission (7.95 KB, patch)
2018-05-15 23:53 UTC, Katrin Fischer
Details | Diff | Splinter Review
Bug 2426: Remove deprecated management permission (8.62 KB, patch)
2018-05-16 00:34 UTC, Katrin Fischer
Details | Diff | Splinter Review
Bug 2426: Remove deprecated management permission (8.67 KB, patch)
2018-05-22 17:12 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 2426: Remove deprecated management permission (8.77 KB, patch)
2018-05-25 09:49 UTC, Marcel de Rooy
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 00:51:03 UTC


---- Reported by nengard@gmail.com 2008-07-30 07:50:34 ----

# management Set library management parameters  ** deprecated

on: cgi-bin/koha/members/member-flags.pl

[09:38]  <nengard> what is this permission for?  "management Set library management parameters"  when I set this permission it's the same as just having catalogue permissions
[09:39]  <nengard> do we have a list of what each of these do
[09:40]  <rch> nengard: this should control access to the bulk of the Administration fcns.
[09:42]  * ccatalfo has quit (Read error: 110 (Connection timed out))
[09:42]  <gmcharlt> nengard: but it's basically deprecated in favor of the parameters permission for dealing with the Adminstration form - doesn't control much directly 
[09:43]  <nengard> gmcharlt, it doesn't show the administration link ... should it? or should we have it removed as a permission?
[09:44]  <gmcharlt> nengard: ultimately, it should probably just be removed - parameters permission now covers things



---- Additional Comments From jmf@liblime.com 2008-08-08 05:31:33 ----

Good for 3.2, or whenever we get around to expanding permissions



---- Additional Comments From nengard@gmail.com 2009-04-18 14:04:50 ----

Just wanted to bump this up since we are working on permissions for 3.2 now.



---- Additional Comments From joe.atzberger@liblime.com 2009-05-28 17:44:29 ----

The only template using CAN_user_management is header.inc, as follows:

<!-- TMPL_IF NAME="IndependantBranches" -->
    <!-- TMPL_IF NAME="CAN_user_management" --> (<a href="/cgi-bin/koha/circ/selectbranchprinter.pl">Set</a>)<!-- /TMPL_IF -->
<!-- TMPL_ELSE --> 
    (<a href="/cgi-bin/koha/circ/selectbranchprinter.pl">Set</a>)
<!-- /TMPL_IF --> 

So basically it is just an exception case to IndependentBranches to put the link for choosing a new branch.  But that is bogus, because selectbranchprinter doesn't respect the management permission anyway.  Instead it looks for "circulate_remaining_permissions".

The ability to set a different branch for the session should actually be a subpermission of the general login permissions "catalogue" (Librarian interface), since it should be logically divorced from any circulate function.  



---- Additional Comments From joe.atzberger@liblime.com 2009-05-29 14:54:46 ----

So I now consider the main problem to be that IndepdendantBranches is essentially broken with respect to the way it "secures" the Set link.  

As a granular permission, catalogue=>setbranch would make sense, but that wouldn't fix it for non-granular Indy branches, since they would no longer be able to control the appearance of that link separately (everyone w/ "catalogue" would see it).  

In reality that is all they are controlling, the appearance of the link.  The user can still go to selectbranches.pl and set a new branch (they just don't see the link).  So that represents a security failure.  I'm upgrading the severity accordingly.   

I'm open to suggestions about the best way to fix it, but using a different top level permission (i.e. "management") cannot be it.  That would split the security model for the page, and therefore for the links to the page, as currently seen.

I think selectbranchprinter.pl and circulation.pl need to be refactored.  The branch-setting has to happen at selectbranchprinter and NOT be a post back to circulation.pl.  After that is successful, it can redirect to circulation (or HTTP_REFERER).



---- Additional Comments From gmcharlt@gmail.com 2009-05-29 19:07:58 ----

[13:13]  <atz> gmcharlt: would appreciate feedback on http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2426
[13:15]  <atz> basically the IndyBranches implementation for controlling "Set branch" is fractured 
[13:16]  <atz> and whatever fix I implement will reveal that... i.e. "yuo broke it!"
[13:29]  <gmcharlt> atz: some thoughts about it
[13:29]  <gmcharlt> 1. this is a good candidate for AJAX - no need to redirect at all
[13:30]  <atz> good thought
[13:30]  <gmcharlt> 2. catalogue->setbranch is OK as a granular permission
[13:30]  <gmcharlt> 3. indybranches is orthogonal to user permissions in this case, but that's OK for now
[13:31]  <gmcharlt> although potentially it could implement the restriction by overriding the value of a particular users setbranch permission
[13:31]  <atz> yeah, system groups will inevitably come into play here
[13:34]  <atz> for (3) are you saying it is OK to leave the manage permission in play for this weird indy branches exception case?
[13:35]  <atz> that would make the bug an INVALID
[13:35]  <gmcharlt> no, the permission should go away
[13:35]  <atz> so basically we'll be showing the link to indy branches users, even if they can't use it
[13:35]  <gmcharlt> and be replaced a test on the indybranch syspref and whether or not the user is a superlibrarian or has cataloge->changebranch
[13:36]  <atz> superlibrarian gets all user permissions already
[13:37]  <gmcharlt> true
[13:40]  <atz> gmcharlt: what do you think about a psuedo permission for setbranch?  i.e., granular permissions would populate it from catalogue:setbranch but it would still exist for non-granular
[13:40]  <atz> ?
[13:40]  <gmcharlt> sounds reasonable
[13:42]  <atz> i'll give it a try



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 00:51 UTC  ---

This bug was previously known as _bug_ 2426 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2426

Actual time not defined. Setting to 0.0
CC member bchurch@ptfs.com does not have an account here
CC member joe.atzberger@liblime.com does not have an account here

Comment 1 Katrin Fischer 2011-04-25 10:10:26 UTC
This is a real old bug. I don't think we have the permission 'management Set library management parameters' in our granular permissions system that is now standard.

Does the bug still exist or is it working correctly for IndependentBranches now?
Comment 2 Magnus Enger 2011-04-25 10:47:36 UTC
"management Set library management parameters" is still there, not sure about what it does, though.
Comment 3 Nicole C. Engard 2011-04-25 11:47:08 UTC
It is still there and as the chat shows I was told that it doesn't do anything ... so the question is why aren't we removing it?
Comment 4 Owen Leonard 2011-04-25 12:44:49 UTC
The original question is still unanswered: How do we handle the permission to set the branch when IndenpendantBranches is turned on:

            <strong>[% LoginBranchname %]</strong>
            [% IF ( IndependantBranches ) %]
                [% IF ( CAN_user_management ) %]
                    (<a href="/cgi-bin/koha/circ/selectbranchprinter.pl">Set</a>)
                [% END %]
            [% ELSE %]
                (<a href="/cgi-bin/koha/circ/selectbranchprinter.pl">Set</a>)
            [% END %]

It sounds like gmcharlt proposed a new granular permission, catalogue->setbranch. I'm not sure what atz meant by "a psuedo permission," but if any work followed from that it's probably locked up in LEK now.
Comment 5 Katrin Fischer 2014-02-18 06:44:37 UTC
*** Bug 11776 has been marked as a duplicate of this bug. ***
Comment 6 Katrin Fischer 2015-02-12 10:26:12 UTC
It appears the only remaining code for this permission has been changed since and now also checks for another permission:


 66                         [% IF ( CAN_user_management || CAN_user_editcatalogue_edit_catalogue ) %]
67                     <li>
68                         <a class="toplinks" href="/cgi-bin/koha/circ/selectbranchprinter.pl">Set library</a>
69                     </li>
70                         [% END %]

Might be a good time to finally remove the permission?
Comment 7 Katrin Fischer 2018-05-15 23:53:49 UTC Comment hidden (obsolete)
Comment 8 Katrin Fischer 2018-05-16 00:34:41 UTC
Created attachment 75349 [details] [review]
Bug 2426: Remove deprecated management permission

After review of the code it turns out that the management permission
that has been marked as deprecated a long time ago, does not have
any function.

The patch removes all remaining code related to it.

To test:
- Make sure you have a patron with the management permission
- Apply patch
- Run database update
- Check everything still works as expected

Bonus:
borrowers.flags is recalculated for patrons with management
permission.

To check:
- Create some 'permission twins' with and without management
  permission
- Note the value in borrowers.flags
- Apply patch, don't run database update
- Save permissions from GUI for one of the twins
- Note the newly calculated value
- Run database update
- Now both twins should have the same borrowers.flags value
Comment 9 Owen Leonard 2018-05-22 17:12:53 UTC
Created attachment 75476 [details] [review]
Bug 2426: Remove deprecated management permission

After review of the code it turns out that the management permission
that has been marked as deprecated a long time ago, does not have
any function.

The patch removes all remaining code related to it.

To test:
- Make sure you have a patron with the management permission
- Apply patch
- Run database update
- Check everything still works as expected

Bonus:
borrowers.flags is recalculated for patrons with management
permission.

To check:
- Create some 'permission twins' with and without management
  permission
- Note the value in borrowers.flags
- Apply patch, don't run database update
- Save permissions from GUI for one of the twins
- Note the newly calculated value
- Run database update
- Now both twins should have the same borrowers.flags value

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Comment 10 Marcel de Rooy 2018-05-25 09:48:47 UTC
> Bonus:
> borrowers.flags is recalculated for patrons with management
> permission.

No bonus imo.
Comment 11 Marcel de Rooy 2018-05-25 09:49:43 UTC
Created attachment 75562 [details] [review]
Bug 2426: Remove deprecated management permission

After review of the code it turns out that the management permission
that has been marked as deprecated a long time ago, does not have
any function.

The patch removes all remaining code related to it.

To test:
- Make sure you have a patron with the management permission
- Apply patch
- Run database update
- Check everything still works as expected

Bonus:
borrowers.flags is recalculated for patrons with management
permission.

To check:
- Create some 'permission twins' with and without management
  permission
- Note the value in borrowers.flags
- Apply patch, don't run database update
- Save permissions from GUI for one of the twins
- Note the newly calculated value
- Run database update
- Now both twins should have the same borrowers.flags value

Signed-off-by: Owen Leonard <oleonard@myacpl.org>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Comment 12 Nick Clemens 2018-06-08 13:56:51 UTC
Pushed to master for 18.11, awesome work all!
Comment 13 Martin Renvoize 2018-06-11 09:00:12 UTC
Not pushing to 18.05.x as it could surprise unsuspecting librarians during a minor update having this permission disappear (even though it effectively does nothing at present).

Nice fix for 18.11, marking resolved.