https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37052
--- Comment #10 from David Cook <[email protected]> --- (In reply to Christopher Brannon from comment #7) > What if the report has a text box you could list permitted borrower > numbers/card numbers in? If the box is blank, everyone can run it. If it > is populated, only those mention in the box would be able to see/run it. > And obviously, regardless of who is listed, the author and superlibrarians > always have full access to it. To me, the barrier to getting this in Koha isn't technological complexity. It is quite easy to do. Rather, it's getting a few people agreeing on the same design, and that's where things fall apart. For instance, your idea of a text box that could list borrowernumbers/cardnumbers in it implies a column added to the saved_sql table which would store multiple values. However, generally speaking, that's considered a sin in the database design world[1]. Instead, you'd typically create another database table that "maps" borrower DB entries to saved_sql DB entries. But then Koha developers are going to ask "but there's many things we could secure in this way... it doesn't make sense to make a "saved_sql_permissions" or "saved_sql_borrowers" table. Some people might also prefer to use patron category instead of borrowernumber/cardnumber for granting access to a report, which then adds another layer of complexity, which changes the database design. But then if we start thinking about a more generic permission/allowed user model, the challenge to create a design that applies equally well to all parts of Koha becomes overwhelming. And in the process "the perfect becomes the enemy of the good", and everyone ignores it as a task which is just too hard. -- [1] Of course, these days, JSON data types have become a thing in relational databases, which makes it very easy to store and query multi-value data in single database columns. We could add a column to "saved_sql" like "access_rules" and have it contain a JSON object which contains a list of borrowers, a list of category codes, or whatever we want really. Support for JSON in SQL databases isn't vendor agnostic, so you do get more locked-in for the type of SQL database you're using, but it's very power and very flexible. That said, I suppose an argument could be made that the permissions should live in the "borrowers" or "categories" tables, but... that starts leading us back to the perfect being the enemy of the good. -- Hopefully the above shows some of the difficulties that are associated with fixing this particular problem. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
