May 2017 - Koha-bugs - lists.koha-community.org

[Bug 13944] Fund sorting is inconsistent across different parts of Koha
by bugzilla-daemon＠bugs.koha-community.org 08 May '17

08 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13944 --- Comment #4 from Sandre Cunha <cunha(a)monterey.org> --- I think fund name would be the best option. Between our operating and our trust fund budget, we have a lot of fund codes, and sorting by the code would not put the fund lines in any kind of meaningful order. At least if the sort is by fund name, one has the option of adding words or letters to force the sort into the order one wants. The sorting by order of creation is a nightmare when you are trying to create a budget and group things in a logical way. If you miss one, or had a couple of last minute additions, you either have to re-do the whole thing, or just let them hang out at the bottom, rather in a related group. It would be nice to be able to re-sort them, but if the default was to sort by name, this issue would less of a problem. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14850] Funds from inactive budgets appear in 'Funds' dropdown on acqui/invoice.pl
by bugzilla-daemon＠bugs.koha-community.org 08 May '17

08 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14850 Marjorie Barry-Vila <marjorie.barry-vila(a)ccsr.qc.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marjorie.barry-vila(a)ccsr.qc | |.ca -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13944] Fund sorting is inconsistent across different parts of Koha
by bugzilla-daemon＠bugs.koha-community.org 08 May '17

08 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13944 --- Comment #3 from Marjorie Barry-Vila <marjorie.barry-vila(a)ccsr.qc.ca> --- Hi, I prefer too, sort by fund name. But now in 16.11, fund pulldown for an order line ( acqui/neworderempty.pl ) is sort by Fund code. But in acqui/invoice.pl, shipping funds are sort by Name (and other problem, all funds are displayed). Anyone want to works on it? Regards, Marjorie -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12461] Add patron clubs feature
by bugzilla-daemon＠bugs.koha-community.org 08 May '17

08 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12461 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |18559 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18559 [Bug 18559] Koha::Clubs - methods should not get the return type in parameter -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12461] Add patron clubs feature
by bugzilla-daemon＠bugs.koha-community.org 08 May '17

08 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12461 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |18558 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18558 [Bug 18558] Koha::Clubs::get_enrollable explodes if no patron given -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12461] Add patron clubs feature
by bugzilla-daemon＠bugs.koha-community.org 08 May '17

08 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12461 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |18557 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18557 [Bug 18557] Mysqlim CURRENT_DATE in Koha::Clubs::get_enrollable -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7174] Authentication rewriting
by bugzilla-daemon＠bugs.koha-community.org 08 May '17

08 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7174 Lari Taskula <lari.taskula(a)jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #41536|0 |1 is obsolete| | Attachment #41537|0 |1 is obsolete| | --- Comment #24 from Lari Taskula <lari.taskula(a)jns.fi> --- Created attachment 63255 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=63255&action=ed… Bug 7174 - Authentication Rewrite - Core Depends heavily on Buugg 14540, which introduces many tests to spot regression caused by this feature. Introduces a new modular authentication system based on Exception signaling and reusable authentication components/challenges. This system is cross-framework -compatible, currently supporting Mojolicious and CGI, but adding support for any other framework is straightforward. Central idea is to provide a single authentication function to deal with all types of authentication scenarios, REST API, Cookie, Password, LDAP... Also it is important to make a system that is easy to extend and can deal with many future authentication scenarios. Currently only CGI password, LDAP and cookie login is tested. Legacy behaviour is used to deal with other types of authentication. See the attached schematic in Bugzilla for a more architectural overview. Also fixes few bugs related to anonymous_search_history The basic principle is: 1. We get an authentication request from any Web/GUI-framework, for ex CGI. 2. Request is normalized by extracting all necessary authentication data elements to a separate data structure. 3. Based on the found authentication data elements, system decides which authentication route to take. 4. Route implements all challenges needed to authenticate the request. Route returns the authenticated Koha::Borrower or an Exception if login failed. 5. The user environment/session is set/deleted based on the Route result. 6. a Koha::Borrower and the CGISESSID-cookie is returned to the calling framework in the format the framework needs. 7. Framework needs to catch possible exceptions and deal with them. Eg. login failed, no permission, under maintenance. 8. Authentication succeeds and session is set, or failure is reported to user. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14540] Move member-flags.pl to PermissionsManager to better manage permissions for testing.
by bugzilla-daemon＠bugs.koha-community.org 08 May '17

08 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14540 Lari Taskula <lari.taskula(a)jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #63253|0 |1 is obsolete| | --- Comment #25 from Lari Taskula <lari.taskula(a)jns.fi> --- Created attachment 63254 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=63254&action=ed… Bug 14540 - Move member-flags.pl to PermissionsManager to better manage permissions for testing. Currently there is no nice way to grant/revoke permissions for Patrons in Koha. This is a big problem when doing integration testing and when working with permissions using the future REST API. Currently we have one web-script, member-flags.pl, which deals with all permission-related things. Basically it always DELETEs all your permissions and then adds them again with some modifications. There is no internal API for creating permissions and this makes automated testing significantly harder. To create permissions for a test patron, we must decrypt the arcane way of creating koha.borrowers.flags and add user_permissions with brittle SQL-queries. This makes for very messy test scripts, and quite frankly this is hardly ever done in Koha. Also the koha.borrowers.flags-column is pretty horrible. It is 19-bit binary array where each bit tells of the patron has all permissions for the respective permission module. This is very difficult to calculate and the mechanism is hard to understand. This feature is also unnecessary, since we are always interested in having the specific permissions. We don't need to know if one Patron has all the permissions for one module. Also what happens if more subpermissions are added to the module? Existing all-permission-holders lose their all-permissions-status? Instead we could have a nice internal API to work with permissions. My patch introduces a new database structure for permissions (not necessarily better), Koha::Object implementation of the DB structure, and most importantly, a Koha::Auth::PermissionManager which is a gateway to all permissions-related actions. This feature is well tested with unit tests and PageObject integration tests. See the tests for usage examples. Especially the t/db_dependent/Members/member-flags.t I hope you like it :) SELENIUM TESTS: Now that the new permission manager enables setting permissions easily in test environments. This patch introduces more complex PageObject regressions tests. -Logged in branch regression test for Intra. -OPAC password login/logout -OPAC anonymous search history preservation. VOCABULARY: Module (permission_modules) => a module which consists of specific Permissions. Typically covers one Module in Koha. Permission (permission) => a specific Permission of a Module. Granting a Patron the permission to do something. Patron permission (borrower_permissions) => A specific Permission a specific Patron has, eg. the permission to edit bibliographic records. TEST PLAN: -2. Note the permissions a bunch of patrons has. -1. run updatedatabase.pl 0. Observe that those patrons still have the same permissions. For modules which didn't have any subpermissions, a generic subpermission is added and the patrons should have it if they had the existing module permission. Basic login: 1. Go to Koha staff client 2. Make a password login. 3. Browse to any other staff client pages to confirm that the session is active and login persists on other pages. Modify permissions: 1. Go to member-flags.pl (Home â€º Patrons â€º Set permissions) 2. Change your permissions. Save. 3. Go back to member-flags.pl 4. Observe that you see the same permissions you just set. Modify superlibrarian permission: 1. Go to member-flags.pl (Home â€º Patrons â€º Set permissions) 2. Give the superlibrarian-permission. Observe all other permissions vanishing. Save. 3. Go back to member-flags.pl 4. Observe that you see only the superlibrarian-permission active. 5. Observe that the superlibrarian permission is the only top-level permission which doesn't have any subpermissions. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14540] Move member-flags.pl to PermissionsManager to better manage permissions for testing.
by bugzilla-daemon＠bugs.koha-community.org 08 May '17

08 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14540 Lari Taskula <lari.taskula(a)jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #63252|0 |1 is obsolete| | --- Comment #24 from Lari Taskula <lari.taskula(a)jns.fi> --- Created attachment 63253 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=63253&action=ed… Bug 14540 - Move member-flags.pl to PermissionsManager to better manage permissions for testing. Currently there is no nice way to grant/revoke permissions for Patrons in Koha. This is a big problem when doing integration testing and when working with permissions using the future REST API. Currently we have one web-script, member-flags.pl, which deals with all permission-related things. Basically it always DELETEs all your permissions and then adds them again with some modifications. There is no internal API for creating permissions and this makes automated testing significantly harder. To create permissions for a test patron, we must decrypt the arcane way of creating koha.borrowers.flags and add user_permissions with brittle SQL-queries. This makes for very messy test scripts, and quite frankly this is hardly ever done in Koha. Also the koha.borrowers.flags-column is pretty horrible. It is 19-bit binary array where each bit tells of the patron has all permissions for the respective permission module. This is very difficult to calculate and the mechanism is hard to understand. This feature is also unnecessary, since we are always interested in having the specific permissions. We don't need to know if one Patron has all the permissions for one module. Also what happens if more subpermissions are added to the module? Existing all-permission-holders lose their all-permissions-status? Instead we could have a nice internal API to work with permissions. My patch introduces a new database structure for permissions (not necessarily better), Koha::Object implementation of the DB structure, and most importantly, a Koha::Auth::PermissionManager which is a gateway to all permissions-related actions. This feature is well tested with unit tests and PageObject integration tests. See the tests for usage examples. Especially the t/db_dependent/Members/member-flags.t I hope you like it :) SELENIUM TESTS: Now that the new permission manager enables setting permissions easily in test environments. This patch introduces more complex PageObject regressions tests. -Logged in branch regression test for Intra. -OPAC password login/logout -OPAC anonymous search history preservation. VOCABULARY: Module (permission_modules) => a module which consists of specific Permissions. Typically covers one Module in Koha. Permission (permission) => a specific Permission of a Module. Granting a Patron the permission to do something. Patron permission (borrower_permissions) => A specific Permission a specific Patron has, eg. the permission to edit bibliographic records. TEST PLAN: -2. Note the permissions a bunch of patrons has. -1. run updatedatabase.pl 0. Observe that those patrons still have the same permissions. For modules which didn't have any subpermissions, a generic subpermission is added and the patrons should have it if they had the existing module permission. Basic login: 1. Go to Koha staff client 2. Make a password login. 3. Browse to any other staff client pages to confirm that the session is active and login persists on other pages. Modify permissions: 1. Go to member-flags.pl (Home â€º Patrons â€º Set permissions) 2. Change your permissions. Save. 3. Go back to member-flags.pl 4. Observe that you see the same permissions you just set. Modify superlibrarian permission: 1. Go to member-flags.pl (Home â€º Patrons â€º Set permissions) 2. Give the superlibrarian-permission. Observe all other permissions vanishing. Save. 3. Go back to member-flags.pl 4. Observe that you see only the superlibrarian-permission active. 5. Observe that the superlibrarian permission is the only top-level permission which doesn't have any subpermissions. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14540] Move member-flags.pl to PermissionsManager to better manage permissions for testing.
by bugzilla-daemon＠bugs.koha-community.org 08 May '17

08 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14540 Lari Taskula <lari.taskula(a)jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #42410|0 |1 is obsolete| | Attachment #42434|0 |1 is obsolete| | Attachment #42550|0 |1 is obsolete| | Attachment #44490|0 |1 is obsolete| | --- Comment #23 from Lari Taskula <lari.taskula(a)jns.fi> --- Created attachment 63252 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=63252&action=ed… Bug 14540 - Move member-flags.pl to PermissionsManager to better manage permissions for testing. Currently there is no nice way to grant/revoke permissions for Patrons in Koha. This is a big problem when doing integration testing and when working with permissions using the future REST API. Currently we have one web-script, member-flags.pl, which deals with all permission-related things. Basically it always DELETEs all your permissions and then adds them again with some modifications. There is no internal API for creating permissions and this makes automated testing significantly harder. To create permissions for a test patron, we must decrypt the arcane way of creating koha.borrowers.flags and add user_permissions with brittle SQL-queries. This makes for very messy test scripts, and quite frankly this is hardly ever done in Koha. Also the koha.borrowers.flags-column is pretty horrible. It is 19-bit binary array where each bit tells of the patron has all permissions for the respective permission module. This is very difficult to calculate and the mechanism is hard to understand. This feature is also unnecessary, since we are always interested in having the specific permissions. We don't need to know if one Patron has all the permissions for one module. Also what happens if more subpermissions are added to the module? Existing all-permission-holders lose their all-permissions-status? Instead we could have a nice internal API to work with permissions. My patch introduces a new database structure for permissions (not necessarily better), Koha::Object implementation of the DB structure, and most importantly, a Koha::Auth::PermissionManager which is a gateway to all permissions-related actions. This feature is well tested with unit tests and PageObject integration tests. See the tests for usage examples. Especially the t/db_dependent/Members/member-flags.t I hope you like it :) SELENIUM TESTS: Now that the new permission manager enables setting permissions easily in test environments. This patch introduces more complex PageObject regressions tests. -Logged in branch regression test for Intra. -OPAC password login/logout -OPAC anonymous search history preservation. VOCABULARY: Module (permission_modules) => a module which consists of specific Permissions. Typically covers one Module in Koha. Permission (permission) => a specific Permission of a Module. Granting a Patron the permission to do something. Patron permission (borrower_permissions) => A specific Permission a specific Patron has, eg. the permission to edit bibliographic records. TEST PLAN: -2. Note the permissions a bunch of patrons has. -1. run updatedatabase.pl 0. Observe that those patrons still have the same permissions. For modules which didn't have any subpermissions, a generic subpermission is added and the patrons should have it if they had the existing module permission. Basic login: 1. Go to Koha staff client 2. Make a password login. 3. Browse to any other staff client pages to confirm that the session is active and login persists on other pages. Modify permissions: 1. Go to member-flags.pl (Home â€º Patrons â€º Set permissions) 2. Change your permissions. Save. 3. Go back to member-flags.pl 4. Observe that you see the same permissions you just set. Modify superlibrarian permission: 1. Go to member-flags.pl (Home â€º Patrons â€º Set permissions) 2. Give the superlibrarian-permission. Observe all other permissions vanishing. Save. 3. Go back to member-flags.pl 4. Observe that you see only the superlibrarian-permission active. 5. Observe that the superlibrarian permission is the only top-level permission which doesn't have any subpermissions. -- You are receiving this mail because: You are watching all bug changes.

1 0