https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34460
--- Comment #12 from Christopher Brannon <[email protected]> --- (In reply to Andrew Fuerste-Henry from comment #11) > Overall, this code does not stop a patron from *having* permissions. It only > stops a user from seeing, adding, or removing the patron's permissions. > > If ClearPermissionsAutomatically is set to "Don't enable," once a patron > with permissions is moved to a category with Can Have Permissions set to No, > that patron's permissions cannot be seen or changed but are still in effect. > This would certainly lead to confusion. > > Additionally, this code doesn't do anything to stop permissions from being > added to patron accounts via methods other than the Set Permissions page. > Many libraries use ByWaters Batch Permissions Modifier plugin: > https://github.com/bywatersolutions/koha-plugin-batch-permissions-modifier. > The plugin is able to add permissions to any patron, regardless of the Can > Have Permissions value of their category. Ah, well that is good, regarding it not removing existing permissions, but if "Can have permissions" changes normal behavior, then it stands to reason that it shouldn't be done. New features are supposed to preserve behavior prior to the upgrade, so if it is changing something out of the norm, even if it doesn't cripple access, it still is against common practice. And on the topic of the batch permissions modifier, I am not sure what good this is if that plugin is just an easy backdoor. If we are going to lock things down, we shouldn't have a way to get around it like that. Thoughts? -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected] website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
