https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |martin.renvoize@ptfs-europe |ity.org |.com -- 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=37893 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Migrate some SIP |Migrate some SIP |configuration into the |configuration into the |staff client |staff interface -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Martin Renvoize (ashimema) <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|martin.renvoize@ptfs-europe |pedro.amorim@ptfs-europe.co |.com |m -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Martin Renvoize (ashimema) <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle@bywatersolutions.com, | |nick@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #172530|0 |1 is obsolete| | --- Comment #2 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- Created attachment 172584 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=172584&action=edit SIPconfig.xml into DB schema sip_institution should be a 1 to 1 with sip_policy, even though SIPconfig.xml technically allows for multiple policies per institution, the template SIPconfig.xml only has one policy per institution and as I understand it the SIP code logic expects only one policy per institution. This being the case, and policies not relating to anything else, there's no reason to have a separate table for policies specifically and these columns can be merged into sip_institutions instead. Thoughts? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |37301 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37301 [Bug 37301] Further improve how we build Vue components -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 --- Comment #4 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- (In reply to Kyle M Hall (khall) from comment #3)

I do note the image has institutions and accounts being one to one, but they should be one to many.

100%. Tyvm. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |38201 CC| |pedro.amorim@ptfs-europe.co | |m Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38201 [Bug 38201] VueJS architecture rethink -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- URL|https://github.com/PTFS-Eur |https://github.com/PTFS-Eur |ope/koha/commits/bug_37893/ |ope/koha/commits/new_bug_37 | |893/ -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew.auld@ptfs-europe.com | |, | |martin.renvoize@ptfs-europe | |.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Lari Strand <lmstrand@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lmstrand@gmail.com --- Comment #6 from Lari Strand <lmstrand@gmail.com> --- I'm getting error: DEV atomic update /home/lmstrand/Koha25/installer/data/mysql/atomicupdate/bug_37893.pl [14:58:31]: Bug 37893 - Move SIPconfig.xml to database ERROR: {UNKNOWN}: DBI Exception: DBD::mysql::db do failed: Can't create table `kohacomm`.`sip_accounts` (errno: 150 "Foreign key constraint is incorrectly formed") at /home/lmstrand/Koha25/C4/Installer.pm line 771 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 --- Comment #8 from Lari Strand <lmstrand@gmail.com> --- Maybe the passwords could be obscured by ***** by default in the sip2 accounts view and could be shown only when a "view password" button is clicked or something for security reasons? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 --- Comment #10 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- Hi Lari, your feedback and testing is very much appreciated. Thank you for looking. (In reply to Lari Strand from comment #6)

I'm getting error: DEV atomic update /home/lmstrand/Koha25/installer/data/mysql/atomicupdate/bug_37893.pl [14:58:31]: Bug 37893 - Move SIPconfig.xml to database ERROR: {UNKNOWN}: DBI Exception: DBD::mysql::db do failed: Can't create table `kohacomm`.`sip_accounts` (errno: 150 "Foreign key constraint is incorrectly formed") at /home/lmstrand/Koha25/C4/Installer.pm line 771

This was an oversight, I've corrected it (sip_institutions needs to be created before sip_accounts) and squashed to https://github.com/PTFS-Europe/koha/commit/c0937ae0b8644fd42c4b84687235407cf... (In reply to Lari Strand from comment #7)

We also have multiple sip config files on our server (under SIPconfig path) that should be iterated through and the file locations are on a different location where the atomicupdate is trying to find them. Maybe the path to the SIPConfig files could be set and read from koha-conf.xml or something?

This is an interesting use case, apologies for my ignorance but how exactly do you have this set up? i.e. how does Koha natively know that it needs to look for multiple files on a certain directory? (In reply to Lari Strand from comment #8)

Maybe the passwords could be obscured by ***** by default in the sip2 accounts view and could be shown only when a "view password" button is clicked or something for security reasons?

I love this idea, this needs to be built into bug bug 38201 as a "password" type form field, on the framework, and then all modules would be able to use it, including this work here of course. (In reply to Lari Strand from comment #9)

"We also have multiple sip config files on our server (under SIPconfig path) that should be iterated through" This could be difficult to do and managed via the UI, so as a workaround combining our config files into one and running just that sip server process would be an ok solution for us.

Coming back to this, is your setup a custom thing or a Koha native thing? If Koha natively supports multiple SIPconfig.xml files then this work needs to consider that. I've not considered it because I'm not aware of it being possible but I'm not very knowledgeable in how SIP may or may not be configured. If this is something you have set up in a custom manner, then yes I think adapting your custom set up for when upgrading into this module is the best course of action. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew@bywatersolutions.com Status|Needs Signoff |Failed QA --- Comment #11 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- We've been testing this with much success! We've successfully configured connections and run tests of most available options. We have a few things yet to confirm. Right up front, though, we're having trouble with the modal to restart SIP after editing the configuration. SIP did not restart when we selected Yes. Our changes did not save when we selected No. Either way, the modal kept coming back even though we checked the "Don't ask again" checkbox. Less pressingly, it'd be nice to get tooltips in the Institutions setup explaining what's wanted in each field. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Marion Durand <marion.durand@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marion.durand@biblibre.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 John Vinke <jvinke@austinseminary.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jvinke@austinseminary.edu Status|Needs Signoff |Failed QA --- Comment #14 from John Vinke <jvinke@austinseminary.edu> --- Failed QA At step 4 it is unclear what value should be set in implementation field. At step 6, nothing will import if you have created institutions, accounts, etc. Can we please have a more detailed test plan that covers all of the patches? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #16 from David Cook <dcook@prosentient.com.au> --- I could see adding "accounts" and "institutions", but not "listeners". I suppose for a Koha system where they don't have sysadmin it would be handy if they could define "listeners", but for a multi-tenanted system you don't want Koha instances being able to define the listeners. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Pedro Amorim <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff --- Comment #18 from Pedro Amorim <pedro.amorim@openfifth.co.uk> --- (In reply to John Vinke from comment #14)

Failed QA

Hi John, thank you.

At step 4 it is unclear what value should be set in implementation field.

I pushed a new commit that should address this: https://github.com/openfifth/koha/commit/871ed139317ea56799909b5af8190b15470... Please let me know.

At step 6, nothing will import if you have created institutions, accounts, etc.

Can we please have a more detailed test plan that covers all of the patches?

I agree. I've made the previous 2 test plan comments obsolete to avoid causing future confusion. I've updated the test plan on the last tests patch on the branch and also copied here on my previous comment. The revised test plan should no longer cause you to experience this, i.e. first creating manually then import through updatedatabase. However, updatedatabase not adding subsequent data is intentional, as the data being re-inserted will fail due to duplicate keys, but the 'INSERT IGNORE INTO' skips the error. Furthermore, because updatedatabase is intended to run at upgrade time, it is not expected to have database data at that point, only data in the SIPconfig.xml file. If you want to run updatedatabase multiple times to test different setups or SIPconfig.xml files, the data should be removed beforehand to avoid duplicate clashes: delete from sip_accounts; delete from sip_institutions; delete from sip_listeners; delete from sip_server_params; delete from sip_system_preference_overrides; -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 --- Comment #20 from Magnus Enger <magnus@libriotech.no> ---

I'm out of my depth when it comes to the inner workings of SIP, and the following may be a dumb question, but how does one know if a system is multi-tenanted or not? The UI configuration of listeners could be tied to this, i.e. only allow CRUD of listeners if not multi-tenanted.

I think multi-tenanted here means "more than one instance running on the same server". You don't want different instances to set up their SIPservers to listen on the same port. Not sure how to solve that in code, though. It might have to require people from the different instances to just talk to each other? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Pedro Amorim <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- URL|https://github.com/PTFS-Eur |https://github.com/openfift |ope/koha/commits/new_bug_37 |h/koha/commits/new_bug_3789 |893/ |3 --- Comment #22 from Pedro Amorim <pedro.amorim@openfifth.co.uk> --- Magnus and David, please take a look at this commit when you have the chance: https://github.com/openfifth/koha/commit/a0a003a5aaec12ac8103c3b4512478ddda1... -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 --- Comment #23 from David Cook <dcook@prosentient.com.au> --- (In reply to Pedro Amorim from comment #21)

In relation to the issue of different listeners (from different Koha instances) using the same port, as far as I can tell this is not checked/enforced currently, i.e. this is already an issue/possibility before moving it into the module, though I agree that it may expose / make this more prone to happening since it'll become editable in the UI.

(In reply to Pedro Amorim from comment #22)

Magnus and David, please take a look at this commit when you have the chance: https://github.com/openfifth/koha/commit/ a0a003a5aaec12ac8103c3b4512478ddda1fbb8b

If you have 1 sysadmin managing N SIPconfig.xml, you have 1 person managing the IP addresses and ports across all the instances though, so conflicts aren't a problem. What I'm trying to say is that - as a vendor sysadmin - I don't want Koha library admins being able to configure the IP address and port number for the listener. There would be some potential for malicious abuse to the underlying host system if a user was able to dictate the IP address and port used. It would probably be somewhat limited since it would be running as the Koha user, so it wouldn't be able to bind to a privileged port, but it's still not great. Realistically, in production, the sysadmin will have likely set up stunnel and have that proxying to specific ports they've defined in SIPconfig.xml. There's also the case of the sysadmin or network admin setting up the firewalls. So I'm not quite sure of the benefit to moving the listener config into the web UI? I can only see the downsides. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lisette@bywatersolutions.co | |m Status|Needs Signoff |Signed Off --- Comment #25 from Lisette Scheer <lisette@bywatersolutions.com> --- This worked great. Andrew and I tested. As far as listeners go, we would have no problem if community wanted to not make listeners editable. It seems like the biggest place things could go wrong with this. It would be nice to see the information, but editing it could cause big headaches. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 carthur@slolibrary.org <carthur@slolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |carthur@slolibrary.org -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 --- Comment #28 from carthur@slolibrary.org <carthur@slolibrary.org> --- Tested this successfully and I'm signing off on it. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 --- Comment #31 from Pedro Amorim <pedro.amorim@openfifth.co.uk> --- (In reply to David Cook from comment #29)

Theoretically, you could DOS a server (accidentally or maliciously) by feeding in server-params that fill up the process table.

Can you please provide an example / test plan to reproduce / replicate this so I can address it? (In reply to David Cook from comment #30)

I agree with the original idea that "accounts" and "institutions" should be moved into the DB/web UI, but "listeners" and "server-params" really should not be.

"syspref_overrides"... I'm not familiar enough with the use of that in the SIP server, so I don't have ready comment on that one.

You are proposing that only the accounts and institutions part is moved out of SIPConfig.xml. Everything else related to SIP configuration is kept in SIPConfig.xml. Is that correct? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 --- Comment #33 from Marion Durand <marion.durand@biblibre.com> --- I think that syspref_override car also be migrated in the interface -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 --- Comment #34 from David Cook <dcook@prosentient.com.au> --- Sorry my bug mail is broken so I didn't get this. Just noticed your response by chance... (In reply to Pedro Amorim from comment #31)

(In reply to David Cook from comment #29)

...

Theoretically, you could DOS a server (accidentally or maliciously) by feeding in server-params that fill up the process table.

Can you please provide an example / test plan to reproduce / replicate this so I can address it?

Just looking up the process limits now. It looks like filling up the process table might not be possible when running the SIP server as a non-root user, since non-root users should have limits on the number of processes they can run. So it looks like I might be wrong there. But you could still create problems even as a non-root user. Basically just put the your min_servers, max_servers, and min_spare_servers to very high values. For instance, max_servers 500000 and min_spare_servers 450000. Keep in mind that the server-params are passed to the SIP server completely un-checked and un-sanitized, and that all parameters listened in the "CONFIGURATION FILE" section of Net::Server::PreFork can be used. It's just way too much control.

(In reply to David Cook from comment #30)

...

I agree with the original idea that "accounts" and "institutions" should be moved into the DB/web UI, but "listeners" and "server-params" really should not be.

"syspref_overrides"... I'm not familiar enough with the use of that in the SIP server, so I don't have ready comment on that one.

You are proposing that only the accounts and institutions part is moved out of SIPConfig.xml. Everything else related to SIP configuration is kept in SIPConfig.xml. Is that correct?

More or less. Basically, I'm saying "listeners" and "server-params" should stay in SIPConfig.xml. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 --- Comment #36 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #34)

table might not be possible when running the SIP server as a non-root user, since non-root users should have limits on the number of processes they can run. So it looks like I might be wrong there.

But you could still create problems even as a non-root user.

Basically just put the your min_servers, max_servers, and min_spare_servers to very high values. For instance, max_servers 500000 and min_spare_servers 450000.

If you wanted to check for the DOS, I'd say up those more to 5000000 for max_servers and 4500000 for min_spare_servers. You might need "min_servers" to match "min_spare_servers". I can't quite recall. (Taking a quick look at the code and yeah it looks like min_serves must be more than min_spare_servers at least.) Overall, just try to break stuff. Set log_level to 4 and change log_file to /tmp/hack_file.log or something else writeable by the Koha user (like /etc/koha/sites/<koha_instance>/hack_file.log) and try to fill up the file system and cause crashes that way. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Marion Durand <marion.durand@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cbrannon@cdalibrary.org --- Comment #38 from Marion Durand <marion.durand@biblibre.com> --- *** Bug 21935 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 --- Comment #40 from Pedro Amorim <pedro.amorim@openfifth.co.uk> --- (In reply to Marion Durand from comment #39)

Just an idea here (but it might be managed in a separate bug after this one is pushed), it would be amazing to be able to duplicate all translation (screen_msg_regx) from an account to another. And even more to export and import all translation for transfer between Koha.

It is currently quite difficult to manage translation when maintaining multiple instances which all have multiple login.

Would a 'duplicate' (full resource) feature address this? The idea being you'd duplicate an existing SIP2 account (create a new one with values from previous already filled in), keep the things you want (e.g. screen_msg_regx) and remove/change the rest? I ask this because bug 38201 (that blocks this one) aims to move development towards a more framework oriented approach. If this 'duplicate' feature is developed at the framework level, every VueJS module would be able to make use of it (including this SIP2 module), as this 'duplicate' functionality would certainly be useful in other modules / use cases (?) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=35369 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Brendan Lawlor <blawlor@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |blawlor@clamsnet.org -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Pedro Amorim <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- URL|https://github.com/openfift |https://github.com/openfift |h/koha/commits/new_bug_3789 |h/koha/commits/final_bug_37 |3 |893 Status|Failed QA |Needs Signoff --- Comment #42 from Pedro Amorim <pedro.amorim@openfifth.co.uk> --- Hi all, I've revisited this: - A third rewrite has been done on the module to adhere to the patterns introduced by pushed bug 38201 (VueJS composition API, etc) - Server params and listeners have been removed from the UI module and are kept in SIPConfig.xml as per QA comments by David Cook. - Cache is now utilized to check for the last time an account, an institution or a system preference override has been updated. When a new SIP request comes in, it checks if SIP configuration has been updated and does a new read from the database if so. This allows for changes that are made by the UI to reflect on the SIP server without needing a server restart. QA script complaints: - Files were added+removed in the same patch. This refers to the server params+listeners functionality that once existed but has since been purged. - The above happens because I've opted to not squash any patches. This project has gone for over a year (on and off) and contains a patch co-authored by Martin Renvoize and a patch co-authored by Mark Hofstetter. - Some database columns are tinyint but not boolean: lost_block_checkout, lost_block_checkout_value, lost_status_for_missing. These are false positives as these are all intentionally tinyint not boolean. - I believe errors on SIPServer.pm related to pod_coverage are false positives coming from old methods that have non-conformant pod code, not by code added on this patchset. Test plan remains the same. However, because many code changes have happened, I'm asking those who tested before to please test again when convenient. Test plan for the whole module: [MODULE UI TESTING] 1) Checkout the branch and reset_all 2) Run 'updatedatabase'. The contents from /etc/koha/sites/kohadev/SIPConfig.xml have been migrated to the database and should be accessible in the UI. 3) Visit the administration page: http://localhost:8081/cgi-bin/koha/admin/admin-home.pl 4) Notice the new 'Self-service circulation (SIP2)' item under 'Patrons and circulation'. Click it. 5) Notice you are now on the new SIP2 module. Create some institutions, accounts, listeners, etc. Play around with the forms. 6) Confirm all the data has been migrated correctly, and is editable in the UI as expected. [SIP TESTING] 1) On ktd, run the following SIP emulator command: $ perl misc/sip_cli_emulator.pl -su koha -sp koha -l kohalibrary --host localhost --patron 42 -m patron_information 2) Note that the response message contains 'Greetings from Koha'. 3) Using the module UI, visit SIP accounts: http://localhost:8081/cgi-bin/koha/sip2/accounts 4) Find the SIP account that has 'koha' as login. Click edit. 5) Scroll down to 'SIP response mappings' and click 'Add new screen msg regex'. 6) On 'Find', enter 'Greetings from Koha'. On 'Replace', enter 'Hello from 37893 test plan'. Save. 7) Repeat the sip command from 1). Note that 'Greetings from Koha has been replaced with 'Hello from 37893 test plan', without having to restart the SIP server. [OPTIONAL] 1) You can repeat the previous steps in [MODULE UI TESTING] but edit the contents of /etc/koha/sites/kohadev/SIPConfig.xml beforehand with a more complex and thorough configuration (something resembling a real SIPConfig.xml) 2) After updating the contents of SIPConfig.xml, restart SIP: koha-sip --restart 3) Test the module again, verify the contents have been migrated as expected. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Pedro Amorim <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff --- Comment #44 from Pedro Amorim <pedro.amorim@openfifth.co.uk> --- (In reply to Andrew Fuerste-Henry from comment #43)

All values from the SIP config imported successfully. All functionality worked as well with these patches as it does in current main. We could not get the default example bin sorting rule to work with this patch, but we couldn't get it to work on current main, either.

However, failing QA due to test failures in the QA tool.

Test Summary Report ------------------- /kohadevbox/koha/t/db_dependent/api/v1/sip2_accounts.t (Wstat: 512 (exited 2) Tests: 6 Failed: 2) Failed tests: 3, 6 Non-zero exit status: 2 Files=1, Tests=6, 5 wallclock secs ( 0.01 usr 0.00 sys + 3.73 cusr 0.34 csys = 4.08 CPU) Result: FAIL

I can't reproduce this, the QA script only comes back with the false positives I mentioned above, nothing about tests files: Running tests (4) * Proving /kohadevbox/koha/t/db_dependent/Koha/SIP2/SIP2ModuleMigration.t PASS * Proving /kohadevbox/koha/t/db_dependent/api/v1/sip2_accounts.t PASS * Proving /kohadevbox/koha/t/db_dependent/api/v1/sip2_institutions.t PASS * Proving /kohadevbox/koha/t/db_dependent/api/v1/sip2_system_preference_overrides.t PASS Can you please check again? With fresh ktd data only. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|kyle@bywatersolutions.com |testopia@bugs.koha-communit | |y.org -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA --- Comment #46 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- A few tiny QA follow-ups were added to the branch, and signoff and sponsorship lines were added. All in all, I think this is a great piece of work and really moves Koha forward. I have a suggestion for a follow-up which Pedro is aware of for the future, but it more relates to Vue framework than the SIP interfaces here.. my final follow-up notes it and allows for us to move forward without it by adding a trivial tooltip. Passing QA, please grab the branch in your leisure Lucas :) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 --- Comment #48 from David Cook <dcook@prosentient.com.au> --- Just reiterating that I'm giving this a +1 from me. I think if any issues do pop up... we fix them as they come. This is a good generational shift for Koha's SIP2 server I think. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 --- Comment #50 from David Cook <dcook@prosentient.com.au> --- That all sounds good, Pedro. Thanks for reviewing my notes. (In reply to Pedro Amorim from comment #49)

...

6. The console is full of "Incorrect use of <label for=FORM_ELEMENT>" page errors. The browser says this could negatively affect accessibility tools.

I cannot see this. Can you please provide more information e.g. which page, what browser.

Yep, my bad. I should've been more specific. I can't recall exactly now, but I do have one example which I'll explain and provide a screenshot for. Steps: 0. Open F12 tools (I'm in Chrome but could be Firefox, Edge, whatever) and go to "Console" tab 1. Go to http://localhost:8081/cgi-bin/koha/sip2/sip2.pl 2. Click "Accounts" 3. Click "Edit" on any of the rows 4. In the upper right hand corner, there should be a little red flag with an X on it and a count of around 28 next to it. These are issues that don't generate console messages but still show up as issues in the browser. I think we often ignore them in Koha (and most web apps tbh), but I thought I'd flag it anyway. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 --- Comment #52 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #50)

...

I cannot see this. Can you please provide more information e.g. which page, what browser.

Yep, my bad. I should've been more specific. I can't recall exactly now, but I do have one example which I'll explain and provide a screenshot for.

Looking at this again and I think I see what it means. While many labels have a "for" attribute, they're not for a single form input, so they're not actually usable. "Payment type writeoff" works because it's a simple mapping between the label and the input, but then things like "Holds block checkin" or "Cash register" show up as violations. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Kyle M Hall (khall) <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Failed QA --- Comment #54 from Kyle M Hall (khall) <kyle@bywatersolutions.com> --- For the institutions editor: It appears that deleting an institution will delete all accounts connected to that institution ( which makes sense ) with no warning. It would be best if the editor either warned that "the following accounts will be deleted: act1, act2, etc." or simply prevent deletion of institutions with SIP accounts. It would also be nice if the institution "name" field were limited to a branchcode pulldown since Koha can no longer handle institutions that are not branchcodes. This is a bit out of scope so it's not a blocker. At the very least the tooltip should state that unexpected behavior can occur if it is *not* a valid branchcode. The policy defaults should all default to "yes" in my mind, but I'm open to arguments against it. Retries field should be limited to a max of 999 retries, as the field is 3 characters long. This is a blocker and a minor fix I think. "Staff userid for SIP2 authentication" could be using the patron search in the same way that circulation does to fill in the userid from a list of options. Also not a blocker but would be really nice to have. For the accounts editor: "Convert nonprinting characters" defaults to NULL for imported accounts, but defaults to empty string for created accounts with no option for NULL. The only value I've ever used for this is a space, as it is usually used to convert things like newlines for devices that cannot handle them. This could be either changed to a text field with a checkbox, or a pulldown with options for NULL and space ( and could be added to in the future ), or even a list of authorized values. The simplest solution would be to have empty string convert to NULL. Any of these solutions is acceptable IMO. "Format due date" should have a tooltip explaining it will format the due date in the current DateFormat syspref. "Holds get captured" may need a tool tip? Not a blocker, but I'm not sure how well understood this one will be. "Previous checkout block checkout" should read "Block checkout of items previously or currently checked out by a patron", or maybe "Block previous checkouts" with a tooltip since that is quite verbose. "Send patron home library in AF" can be deprecated but is totally out of scope for this bug. It was for Overdrive but they no longer use this feature ( though we'll need to verify they don't have legacy customers using it if we do ). They now use custom fields of the patron's branchcode. Terminator should default to CRLF. Patron attribute could use a pulldown of attribute types. Could use a tooltip at the least. It would be nice if delimiter, encoding and terminator had the defaults inserted into the database instead of being NULL in the database and showing as empty cells in the accounts table. SIP communication itself appears to work great! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |rel_25_11_candidate -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Pedro Amorim <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |41178 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41178 [Bug 41178] SIP2 module does not notify that linked accounts are deleted when deleting an institution -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Pedro Amorim <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |41180 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41180 [Bug 41180] SIP2 module should auto-complete (search) libraries for institutions name -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 --- Comment #55 from Pedro Amorim <pedro.amorim@openfifth.co.uk> --- (In reply to Kyle M Hall (khall) from comment #54) Thank you so much for your time looking here, Kyle.

For the institutions editor: It appears that deleting an institution will delete all accounts connected to that institution ( which makes sense ) with no warning. It would be best if the editor either warned that "the following accounts will be deleted: act1, act2, etc." or simply prevent deletion of institutions with SIP accounts.

Considering this non-blocker, I hope you understand and agree, for the following reasons: 1) A confirmation box already exists. 2) Only authorized staff members with assigned permissions are able to delete institutions in the first place. 3) This needs a framework doResourceDelete change (i.e. may need additional testing / cause a QA delay here). For that, I've opened bug 41178, and provided patches there. I don't think full module should be blocked by this, and ideally bug 41178 is also looked at by Matt+Joubu.

It would also be nice if the institution "name" field were limited to a branchcode pulldown since Koha can no longer handle institutions that are not branchcodes. This is a bit out of scope so it's not a blocker. At the very least the tooltip should state that unexpected behavior can occur if it is *not* a valid branchcode.

Not a blocker. Opened bug 41180 for future enhancement. Patch updating the tooltip pushed to branch: https://github.com/openfifth/koha/commit/3ecf278a05ed4dc96e0d104ce0d91ce6626...

The policy defaults should all default to "yes" in my mind, but I'm open to arguments against it.

Patch submitted: https://github.com/openfifth/koha/commit/0278df6b9575846c4b67fbae0619cbbe4dd...

Retries field should be limited to a max of 999 retries, as the field is 3 characters long. This is a blocker and a minor fix I think.

Patch submitted: https://github.com/openfifth/koha/commit/24393d6d0b46a976f358673ebda9af37f8d...

"Staff userid for SIP2 authentication" could be using the patron search in the same way that circulation does to fill in the userid from a list of options. Also not a blocker but would be really nice to have.

Not a blocker. Opened bug 41179 for future enhancement.

For the accounts editor: "Convert nonprinting characters" defaults to NULL for imported accounts, but defaults to empty string for created accounts with no option for NULL. The only value I've ever used for this is a space, as it is usually used to convert things like newlines for devices that cannot handle them. This could be either changed to a text field with a checkbox, or a pulldown with options for NULL and space ( and could be added to in the future ), or even a list of authorized values. The simplest solution would be to have empty string convert to NULL. Any of these solutions is acceptable IMO.

Patch ensure empty string is submitted as NULL: https://github.com/openfifth/koha/commit/95e718520f2d9a3bff1f2ed12e2d735b925...

"Format due date" should have a tooltip explaining it will format the due date in the current DateFormat syspref.

Patch updating tooltip: https://github.com/openfifth/koha/commit/6d3373f7ce0565c44a7dda9c78b7ec2fd8e...

"Holds get captured" may need a tool tip? Not a blocker, but I'm not sure how well understood this one will be.

Patch updating tooltip: https://github.com/openfifth/koha/commit/8a59f8935ca82975f5a24a2d849d157bb35...

"Previous checkout block checkout" should read "Block checkout of items previously or currently checked out by a patron", or maybe "Block previous checkouts" with a tooltip since that is quite verbose.

Patch updating label+tooltip: https://github.com/openfifth/koha/commit/019a5d6a511631f793e083ac292b1772fe0...

"Send patron home library in AF" can be deprecated but is totally out of scope for this bug. It was for Overdrive but they no longer use this feature ( though we'll need to verify they don't have legacy customers using it if we do ). They now use custom fields of the patron's branchcode.

No action made here. I'll leave it up to you if you feel necessary to open a new bug for this or not.

Terminator should default to CRLF.

Patch defaulting terminator to CRLF in form: https://github.com/openfifth/koha/commit/412003aeb35d3b5096098d342d0544fa940...

Patron attribute could use a pulldown of attribute types. Could use a tooltip at the least.

Opened bug 41181 for future enhancement. Patch updating field tooltip in form: https://github.com/openfifth/koha/commit/81408e0c1dfd54d74aa49ed68001a3a4f41...

It would be nice if delimiter, encoding and terminator had the defaults inserted into the database instead of being NULL in the database and showing as empty cells in the accounts table.

Patch defaulting delimiter and terminator inserted values in database: https://github.com/openfifth/koha/commit/53670bebfd78bf2eac2ee51ae131f38a384... encoding was skipped as I'm unsure if it should default to utf or ascii and the code appears to consider NULL as a possibility (?). I'm setting this back to PQA as having addressed the feedback but I'm happy to discuss further and/or revisit anything that needs it. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 --- Comment #56 from Kyle M Hall (khall) <kyle@bywatersolutions.com> --- Thank you for the followup bugs and patches! I think this is ready to be pushed! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Failed QA --- Comment #60 from David Cook <dcook@prosentient.com.au> --- Nice catches there, Jonathan. (In reply to Jonathan Druart from comment #59)

11. Missing changes in etc/koha-httpd.conf?

I haven't checked all the places Jonathan mentioned but I have checked this one and in light of bug 41167, I'm marking this as Failed QA -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Pedro Amorim <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |41167 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41167 [Bug 41167] Rewrite Rules missing in etc/koha-httpd.conf -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Pedro Amorim <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=41215 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 --- Comment #63 from Pedro Amorim <pedro.amorim@openfifth.co.uk> --- (In reply to Jonathan Druart from comment #62)

...

Out of scope here? AFAIK the 'dummy' existing config in SIPconfig.xml served only as documentation for all the possible configuration values for accounts + institutions + syspref overrides (which is what is migrated here). Server params and listeners are still read from the SIPconfig.xml file (as per DCook's original QA requirements).

It's a regression for ktd: we are expecting to have a working configuration. See https://gitlab.com/koha-community/koha-misc4dev/-/issues/35 and the related merge request "Issue #35 - Make SIP work out of the box"

C4::SIP::Sip::Configuration::get_configuration only fetches accounts, institutions and syspref_overrides from the database if any exist (in the database). Otherwise it falls back to the old way: reading that data from SIPconfig.xml. This was purposely done to have a smooth transition i.e. if for any reason the data is not in the database, reading from the SIPconfig.xml is still the fallback (until full deprecation in the future(?)). I'm happy to help/follow-up with whatever is needed, though I've not worked on misc4dev before and would appreciate guidance, would it be a new sip_data.sql file under installer/data/mysql/mandatory? Thank you. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 --- Comment #65 from Jonathan Druart <jonathan.druart@gmail.com> --- (In reply to Pedro Amorim from comment #63)

(In reply to Jonathan Druart from comment #62)

...

...

Out of scope here? AFAIK the 'dummy' existing config in SIPconfig.xml served only as documentation for all the possible configuration values for accounts + institutions + syspref overrides (which is what is migrated here). Server params and listeners are still read from the SIPconfig.xml file (as per DCook's original QA requirements).

It's a regression for ktd: we are expecting to have a working configuration. See https://gitlab.com/koha-community/koha-misc4dev/-/issues/35 and the related merge request "Issue #35 - Make SIP work out of the box"

C4::SIP::Sip::Configuration::get_configuration only fetches accounts, institutions and syspref_overrides from the database if any exist (in the database). Otherwise it falls back to the old way: reading that data from SIPconfig.xml. This was purposely done to have a smooth transition i.e. if for any reason the data is not in the database, reading from the SIPconfig.xml is still the fallback (until full deprecation in the future(?)).

I'm happy to help/follow-up with whatever is needed, though I've not worked on misc4dev before and would appreciate guidance, would it be a new sip_data.sql file under installer/data/mysql/mandatory? Thank you.

Open an issue there and we will deal with that later. It seems that we could detect if the dbrev exists, if it exists we can run it and it will populate the DB. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|rel_25_11_candidate, | |RM_priority | Status|Passed QA |Pushed to main --- Comment #67 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- Pushed to main to for 25.11.00, nice work all! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |additional_work_needed -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 --- Comment #69 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- xt/author/pod_coverage.t is failing after this was pushed. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 --- Comment #71 from Pedro Amorim <pedro.amorim@openfifth.co.uk> --- Created attachment 189712 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=189712&action=edit Bug 37893: (QA follow-up): Fix TestBuilder.t To test, run: prove t/db_dependent/TestBuilder.t -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Pedro Amorim <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |41271 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41271 [Bug 41271] pod_coverage.t unintentionally attempts to launch a SIP server when checking SIPServer.pm -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Pedro Amorim <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |additional_work_needed -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)| |25.11.00 released in| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|additional_work_needed | Status|Passed QA |Pushed to main --- Comment #77 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- follow-up pushed to main -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Kyle M Hall (khall) <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |41311 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41311 [Bug 41311] Add ability for SIP to send patron home library ( branchcode ) in AO field -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Katie Bliss <kebliss@dmpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kebliss@dmpl.org -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Bug 37893 depends on bug 38201, which changed state. Bug 38201 Summary: VueJS architecture rethink https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38201 What |Removed |Added ---------------------------------------------------------------------------- Status|Needs documenting |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |41980 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41980 [Bug 41980] SIP codes in the new SIP Config UI could have better descriptions -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |42053 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42053 [Bug 42053] Bug 37893 DBUpdate does not always add the new userflags/permissions -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |42120 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42120 [Bug 42120] Note in SIP Account setup that Institution determines logged-in library -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |42141 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42141 [Bug 42141] Design pattern introduced in 40191 does not work in staff SIP configuration -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Nick Clemens (kidclamp) <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |42447 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42447 [Bug 42447] SIP template fields in the database are too small -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |42774 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42774 [Bug 42774] "sip2" permission missing on upgraded Koha if SIPconfig.xml file doesn't exist -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|additional_work_needed | --- Comment #81 from Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> --- Removing additional_work_needed here as the bug is documented in bug 42778 and should ideally be followed up there. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 Fridolin Somers <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |42547 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42547 [Bug 42547] SIP performance is terrible if sip2_resource_last_modified is missing from memcached -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 --- Comment #83 from Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> --- (In reply to David Cook from comment #82)

Definitely needs documenting still. Just had some queries and I can't find any info.

@Pedro, with https://github.com/openfifth/koha/commit/ 2f2a0541a2166c0bcadb5d98feffd98547fbed07 is the intention that the library can add a standard SIP2 field with the value from a patron attribute?

Hi David, Yes. This is the previous SIPconfig.xml <patron_attribute field="XY" code="CODE" /> feature, now configurable in Administration > SIP 2 > Accounts: - field: the 2-character SIP2 field identifier to send the value in (e.g. XY, or a standard one like AE) - code: the patron attribute type code (Administration > Patron attribute types) Koha takes the patron's value(s) for that attribute and appends them under that SIP field in Patron Status and Patron Information responses. -- You are receiving this mail because: You are watching all bug changes.