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
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?
(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/edbc81199798aa084365a1845188aa24e6ad010b/etc/SIPconfig.xml#L55 ) and the institutions ( https://github.com/Koha-Community/Koha/blob/edbc81199798aa084365a1845188aa24e6ad010b/etc/SIPconfig.xml#L105 ). 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.
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. :)
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?
(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.
love that yes.
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
(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