---- Reported by nengard@gmail.com 2009-12-03 16:54:20 ---- * budget_add_del Add and delete budgets (but can't modify budgets) * budget_manage Manage budgets * budget_modify Modify budget (can't create lines but can modify existing ones) I asked on the Koha list why we needed these three - what makes the budget_manage permission different from the other two? Paul asked that I report a bug because he thinks maybe it's a mistake. --- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:15 UTC --- This bug was previously known as _bug_ 3849 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3849 Actual time not defined. Setting to 0.0 The original assignee of this bug does not have an account here. Reassigning to the default assignee for the component, chris@bigballofwax.co.nz. Previous assignee was jeanandre.santoni@biblibre.com. Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
wow... Nicole, is this entry still relevant ? Do you still have a question ?
Yes, an answer would be nice.
I think you're right, and CAN_user_acquisition_budget_add_del is not used anywhere except in budget.pl, to check that the user has this permission before doing any action (otherwise, prevent adding/modifying) I think/suspect this line can be updated to use budget_manage and we could get rid of add_dell
Created attachment 6099 [details] screenshot of acq permissions Ok, to me acq permissions are still very confusing. Please can someone work out which permission is used where and update the permission texts accordingly? budget_add_del Add and delete budgets (but cant modify budgets) budget_manage Manage budgets budget_modify Modify budget (can't create lines, but can modify existing ones) >Still confusing. contracts_manage Manage contracts group_manage Manage orders & basketgroups order_manage Manage orders & basket order_receive Manage orders & basket >Looks all the same? period_manage Manage periods >What periods? planning_manage Manage budget plannings vendors_manage Manage vendors
(In reply to Katrin Fischer from comment #4) > order_manage Manage orders & basket > order_receive Manage orders & basket > >Looks all the same? I just got a report of this from a library - they were confused - this is still an issue. Nicole
*** Bug 12751 has been marked as a duplicate of this bug. ***
What is the issue here? The permissions don't work (in this case, what are the issues?) or the descriptions need to be updated?
We don't know what the permissions are supposed to do because the descriptions are unclear so we can't tell you if they work :) So we need clearer permission descriptions and then we'll tell you if they work. Nicole
I would say group_manage is for basket groups, order_receive for receiving orders and order_manage for "managing" orders :) By managing I suppose it's any actions != receive.
We still need to fix the descriptions: group_manage Manage orders & basketgroups order_manage Manage orders & basket order_manage_all Manage all orders and baskets, regardless of restrictions on them order_receive Manage orders & basket It should not all say 'manage orders...', but be more specific. Are orders the same as baskets? Or does it means orders and order lines here?
Created attachment 75450 [details] [review] Bug 3849: Improve descriptions of granular acquisition permissions The permissions for acquisitions were not very clearly described. This patch changes the descriptions in the include file (GUI) and in the default SQL. To test: - Go to any patron account in staff - Go to more > permissions - Verify that the meaning of each acquisition permission is clear from the description
Created attachment 75473 [details] [review] Bug 3849: Improve descriptions of granular acquisition permissions The permissions for acquisitions were not very clearly described. This patch changes the descriptions in the include file (GUI) and in the default SQL. To test: - Go to any patron account in staff - Go to more > permissions - Verify that the meaning of each acquisition permission is clear from the description Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Should not we add an update DB entry?
(In reply to Jonathan Druart from comment #13) > Should not we add an update DB entry? ... or remove the "description" column on a separate bug report?
I can add a db update and file a separate report for removing it - then you can pick :)
Created attachment 75618 [details] [review] Bug 3849: (follow-up) Add database update to change descriptions
We still have the descriptions on system preferences too... chose the database update here for now.
Created attachment 75673 [details] [review] Bug 3849: Improve descriptions of granular acquisition permissions The permissions for acquisitions were not very clearly described. This patch changes the descriptions in the include file (GUI) and in the default SQL. To test: - Go to any patron account in staff - Go to more > permissions - Verify that the meaning of each acquisition permission is clear from the description Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Created attachment 75674 [details] [review] Bug 3849: (follow-up) Add database update to change descriptions Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Pushed to master for 18.11, awesome work everybody!
Not pushing to 18.05.x as it could surprise unsuspecting librarians during a minor update. Nice fix for 18.11 though, marking resolved.
Some of this got undone by a later patch, filed a fresh bug to fix it: bug 21966