[Bug 32036] New: Cannot set single sub-permission without also setting the top level flag
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32036 Bug ID: 32036 Summary: Cannot set single sub-permission without also setting the top level flag Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs@lists.koha-community.org Reporter: lucas@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com In permissions, if a top level flag only has a single sub-permission you cannot set the submersion without also setting the top-level permission. For instance, you cannot set the sub-permission 'manage_recalls' without also having the 'recalls' flag set. I think you should be able to set these independently. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32036 --- Comment #1 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I believe this is intentional and not a bug if there is only one sub-permission, it equals the module permissions level. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32036 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|NEW |RESOLVED CC| |dcook@prosentient.com.au --- Comment #2 from David Cook <dcook@prosentient.com.au> --- Choosing the top level flag is the same thing as selecting all sub-permissions. If you go to "Check out and check in items", choose all the sub-permissions and you'll see that the top level flag gets set. (Alternatively, if you just choose the top level flag, it will set all the sub-permissions. Uncheck one sub-permission, and you the top level flag is unchecked.) If you go to https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html&bug=31389&attachment=140563 and look at "Permissions.t", it might be clearer. You get CAN_user_circulate if you're superlibrarian, if you have the top level "circulate" permission, or if you have *any* circulation sub-permission. When you just set "circulate" without specifying individual subpermissions, it automatically gives you all sub-permissions. So setting the "manage_recalls" sub-permission is functionally equivalent to setting the "recalls" top level flag, since there is only . You'll get the exact same authorization. I hope that makes sense. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32036 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nick@bywatersolutions.com Resolution|INVALID |--- Status|RESOLVED |REOPENED --- Comment #3 from Nick Clemens <nick@bywatersolutions.com> --- I think this causes confusion then - either we should always have a single subpermission, or we should only have them if we have two? For OPAC problem reports - we only seem to ever check the top permission For recalls we check the subpermission every time, except once Having two settings with the same behavior seems wrong to me Maybe we need a guideline? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32036 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |In Discussion -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32036 --- Comment #4 from David Cook <dcook@prosentient.com.au> --- (In reply to Nick Clemens from comment #3)
I think this causes confusion then - either we should always have a single subpermission, or we should only have them if we have two?
Confusion for whom?
For OPAC problem reports - we only seem to ever check the top permission For recalls we check the subpermission every time, except once
Having two settings with the same behavior seems wrong to me
What do you mean by "two settings"? For "OPAC problem reports management" and "Recalls", you get the same thing whether you click the top level or the sub-permission, and that's clearly indicated visually. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32036 --- Comment #5 from Nick Clemens <nick@bywatersolutions.com> --- (In reply to David Cook from comment #4)
(In reply to Nick Clemens from comment #3)
I think this causes confusion then - either we should always have a single subpermission, or we should only have them if we have two?
Confusion for whom?
For developers, or users. Why does problem reports have a subpermission, and edit authorities does not?
For OPAC problem reports - we only seem to ever check the top permission For recalls we check the subpermission every time, except once
Having two settings with the same behavior seems wrong to me
What do you mean by "two settings"?
flagsrequired => { recalls => "manage_recalls" } flagsrequired => { recalls => 1 } These are checking two different things, but provide the same answer
For "OPAC problem reports management" and "Recalls", you get the same thing whether you click the top level or the sub-permission, and that's clearly indicated visually.
Sure, but then why is the subpermission added at all? If it is the same as clicking the top level, let's not provide two checkboxes when one will do -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32036 --- Comment #6 from David Cook <dcook@prosentient.com.au> --- (In reply to Nick Clemens from comment #5)
(In reply to David Cook from comment #4)
Confusion for whom?
For developers, or users. Why does problem reports have a subpermission, and edit authorities does not?
Ahh, I understand now. That is confusing. My only thought is that the original developer thought that additional sub-permissions might be added? Aleisha could probably speak to that for recalls.
What do you mean by "two settings"?
flagsrequired => { recalls => "manage_recalls" } flagsrequired => { recalls => 1 }
These are checking two different things, but provide the same answer
That's true (where there is only one sub-permission like recalls). If additional sub-permissions were added, they would mean different things. I suppose that is both a pro and a con...
For "OPAC problem reports management" and "Recalls", you get the same thing whether you click the top level or the sub-permission, and that's clearly indicated visually.
Sure, but then why is the subpermission added at all? If it is the same as clicking the top level, let's not provide two checkboxes when one will do
I think that's the crux of the matter. I suppose one option could be removing unnecessary sub-permissions? Alternatively, we could also grey-out sub-permissions where there's only 1 sub-permission available. That might make it less confusing visually? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32036 --- Comment #7 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to David Cook from comment #6)
(In reply to Nick Clemens from comment #5)
For "OPAC problem reports management" and "Recalls", you get the same thing whether you click the top level or the sub-permission, and that's clearly indicated visually.
Sure, but then why is the subpermission added at all? If it is the same as clicking the top level, let's not provide two checkboxes when one will do
I think that's the crux of the matter.
I suppose one option could be removing unnecessary sub-permissions?
Alternatively, we could also grey-out sub-permissions where there's only 1 sub-permission available. That might make it less confusing visually?
I think you are right, having a module permission with only one sub-permission makes no sense. Recalls should be a top-level permission without sub-permissions and then when something requires a specific permission, a 'remaining recalls permissions' should be added as a second sub-permission, like we have elsewhere (circulate for an example) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32036 --- Comment #8 from Nick Clemens <nick@bywatersolutions.com> --- (In reply to Katrin Fischer from comment #7)
(In reply to David Cook from comment #6)
(In reply to Nick Clemens from comment #5)
For "OPAC problem reports management" and "Recalls", you get the same thing whether you click the top level or the sub-permission, and that's clearly indicated visually.
Sure, but then why is the subpermission added at all? If it is the same as clicking the top level, let's not provide two checkboxes when one will do
I think that's the crux of the matter.
I suppose one option could be removing unnecessary sub-permissions?
Alternatively, we could also grey-out sub-permissions where there's only 1 sub-permission available. That might make it less confusing visually?
I think you are right, having a module permission with only one sub-permission makes no sense. Recalls should be a top-level permission without sub-permissions and then when something requires a specific permission, a 'remaining recalls permissions' should be added as a second sub-permission, like we have elsewhere (circulate for an example)
Just to add, I don't like 'remaining' permisssions - it is very unclear to the end user what exactly these are - I know they are 'everything not listed elsewhere' but it comes off as somewhat ambiguous -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32036 --- Comment #9 from David Cook <dcook@prosentient.com.au> --- (In reply to Nick Clemens from comment #8)
Just to add, I don't like 'remaining' permisssions - it is very unclear to the end user what exactly these are - I know they are 'everything not listed elsewhere' but it comes off as somewhat ambiguous
Agreed. Circulation could benefit from more granular permissions, or even a rename of that one I suppose. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32036 --- Comment #10 from David Cook <dcook@prosentient.com.au> --- (In reply to Nick Clemens from comment #8)
Just to add, I don't like 'remaining' permisssions - it is very unclear to the end user what exactly these are - I know they are 'everything not listed elsewhere' but it comes off as somewhat ambiguous
Of course, Koha's permission system could use a complete overhaul anyway. Personally, I'd like a policy based access control that evaluated subject, object, operation, and perhaps environment. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org