[Bug 33681] New: Omnibus: Allow SIP2 users to be created through the Koha staff interface
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33681 Bug ID: 33681 Summary: Omnibus: Allow SIP2 users to be created through the Koha staff interface Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs@lists.koha-community.org Reporter: wizzyrea@gmail.com QA Contact: testopia@bugs.koha-community.org Let's fix this - libraries ought to be able to create their own SIP users (even the part we currently manage with XML) through the Koha UI. Initial requirements: Create a user that without any touching of server side configuration files can allow a SIP login for the most basic usage of SIP. Allow those users to be configurable with all of the configuration options available through SIPConfig.xml as documented in SIPConfig.xml https://github.com/Koha-Community/Koha/blob/master/etc/SIPconfig.xml -- 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=33681 --- Comment #1 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I think one issue here could be all the extra configuration options we have tied to the SIP logins. Maybe we'd need some kind of default entry in the .xml to make sure we can still connect the config to the user? -- 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=33681 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle@bywatersolutions.com --- Comment #2 from Kyle M Hall <kyle@bywatersolutions.com> --- (In reply to Katrin Fischer from comment #1)
I think one issue here could be all the extra configuration options we have tied to the SIP logins.
Maybe we'd need some kind of default entry in the .xml to make sure we can still connect the config to the user?
I'm certain we can build a UI editor that can handle all those SIP options. I think the two blocks of the xml file that should be moved to the database/ui are the accounts ( https://github.com/Koha-Community/Koha/blob/edbc81199798aa084365a1845188aa24... ) and the institutions ( https://github.com/Koha-Community/Koha/blob/edbc81199798aa084365a1845188aa24... ). One thing to consider is you can currently set institution codes to non-branchcodes, but this makes things explode. We should probably start with a something to codify that SIP institutions *must* be branchcodes now, then it would be trivial to move that part to the database/UI. We have another thought that perhaps would should get rid of accounts/login/institution as the SIP patron's branchcode is functionally equivalent. That's not necessary but could be a good followup. -- 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=33681 --- Comment #3 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Do we need to keep the option to configure in the file for backwards compatibility? I am not sure if it would be possible to migrate. I like the idea of a configuration page. :) -- 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=33681 Liz Rea <wizzyrea@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wizzyrea@gmail.com --- Comment #4 from Liz Rea <wizzyrea@gmail.com> --- I imagine we'd have to support both - perhaps they are additive to each other, i.e. if you have accounts in there, we use them, and if we create any in the UI, those also work? There may be technical reasons why that's not possible. Possibly we do one or the other, via syspref? upgrading koha use SIPConfig.xml until the accounts can be moved or updated, new koha use the UI? -- 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=33681 --- Comment #5 from Kyle M Hall <kyle@bywatersolutions.com> --- (In reply to Liz Rea from comment #4)
I imagine we'd have to support both - perhaps they are additive to each other, i.e. if you have accounts in there, we use them, and if we create any in the UI, those also work?
There may be technical reasons why that's not possible.
Possibly we do one or the other, via syspref? upgrading koha use SIPConfig.xml until the accounts can be moved or updated, new koha use the UI?
There is no reason we can't "merge" the database and xml users together. The only question would be which has precedence in the case of duplicate users. I would say the database version to avoid librarian's creating a sip user only to find it's not working and they don't know why. -- 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=33681 --- Comment #6 from Liz Rea <wizzyrea@gmail.com> --- love that yes. -- 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=33681 --- Comment #7 from Liz Rea <wizzyrea@gmail.com> --- It just occurred to me that also it would be desirable, but perhaps not mvp level, to allow the UI to set which fields to send (of the non-required ones) for privacy reasons -- 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=33681 --- Comment #8 from Kyle M Hall <kyle@bywatersolutions.com> --- (In reply to Liz Rea from comment #7)
It just occurred to me that also it would be desirable, but perhaps not mvp level, to allow the UI to set which fields to send (of the non-required ones) for privacy reasons
Excellent idea! Probably best as a follow up bug for ease of testing -- 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=33681 Lucas Gass <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lucas@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33681 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew@bywatersolutions.com --- Comment #9 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Should this be marked as a dupe of Bug 37893? -- 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=33681 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lisette@bywatersolutions.co | |m Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #10 from Lisette Scheer <lisette@bywatersolutions.com> --- (In reply to Andrew Fuerste-Henry from comment #9)
Should this be marked as a dupe of Bug 37893?
Yes, I think so. *** This bug has been marked as a duplicate of bug 37893 *** -- 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