|
Description
Tomás Cohen Arazi (tcohen)
2024-08-22 14:49:58 UTC
Created attachment 170643 [details] [review] Bug 37711: DB update Created attachment 170644 [details] [review] Bug 37711: DBIC schema Created attachment 170645 [details] [review] Bug 37711: API changes This patch makes the API representation of the identity providers domains match the new metadata. Created attachment 170646 [details] [review] Bug 37711: Domains CRUD update This patch adapts the `Identity provider domains` CRUD page to handle the new configuration options. To test: 1. Have an IdP with some domains set. Make sure there's at least one domain with auto-register enabled and one with it disabled. 2. Apply this patches 3. Run: $ ktd --shell k$ updatedatabase => SUCCESS: Updates successfully 4. Run: k$ yarn build 5. Refresh the IdP domains page => SUCCESS: The domains table shows both OPAC and staff auto-register options. => SUCCESS: The staff auto-register is disabled for both domains => SUCCESS: The OPAC auto-register matches what was set for each domain regarding auto-register (remember that before this patchset, auto-register only works for the OPAC). 6. Play with editing/adding/removing domain configurations => SUCCESS: Things work as expected, values are persisted on the DB correctly. 7. Sign off :-D Created attachment 170647 [details] [review] Bug 37711: Add support for staff interface auto-register on IdP Before this patches, only OPAC auto-registration at login using OAuth2/OIDC IdPs was allowed. This patch makes the staff interface to be able to auto-register new users. On doing it, I had to track down the possible values for the `interface` parameter in the case of the staff interface. Koha::Template::Plugin::AuthClient uses 'staff' internally so I sticked with it. The whole area needs more param validation and exceptions to avoid mistakes for not knowing the valid values. I added some safeguards on the Koha::REST::Plugin::Auth::IdP helpers. They get tested on the added tests. To test: 1. Apply this patch 2. Run: $ prove t/db_dependent/Koha/REST/Plugin/Auth/IdP.t => SUCCESS: Tests pass! 3. Have a valid OAuth... 4. Enable Staff auto-register 5. Login with an external IdP on the staff interface => SUCCESS: It gets registered! Note: it will probably lack permissions to access the staff interface, but you can check on the DB it got registered. 6. Sign off :-D Sponsored-by: ByWater Solutions Created attachment 174090 [details] [review] Bug 37711: DB update Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Created attachment 174091 [details] [review] Bug 37711: DBIC schema Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Created attachment 174092 [details] [review] Bug 37711: API changes This patch makes the API representation of the identity providers domains match the new metadata. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Created attachment 174093 [details] [review] Bug 37711: Domains CRUD update This patch adapts the `Identity provider domains` CRUD page to handle the new configuration options. To test: 1. Have an IdP with some domains set. Make sure there's at least one domain with auto-register enabled and one with it disabled. 2. Apply this patches 3. Run: $ ktd --shell k$ updatedatabase => SUCCESS: Updates successfully 4. Run: k$ yarn build 5. Refresh the IdP domains page => SUCCESS: The domains table shows both OPAC and staff auto-register options. => SUCCESS: The staff auto-register is disabled for both domains => SUCCESS: The OPAC auto-register matches what was set for each domain regarding auto-register (remember that before this patchset, auto-register only works for the OPAC). 6. Play with editing/adding/removing domain configurations => SUCCESS: Things work as expected, values are persisted on the DB correctly. 7. Sign off :-D Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Created attachment 174094 [details] [review] Bug 37711: Add support for staff interface auto-register on IdP Before this patches, only OPAC auto-registration at login using OAuth2/OIDC IdPs was allowed. This patch makes the staff interface to be able to auto-register new users. On doing it, I had to track down the possible values for the `interface` parameter in the case of the staff interface. Koha::Template::Plugin::AuthClient uses 'staff' internally so I sticked with it. The whole area needs more param validation and exceptions to avoid mistakes for not knowing the valid values. I added some safeguards on the Koha::REST::Plugin::Auth::IdP helpers. They get tested on the added tests. To test: 1. Apply this patch 2. Run: $ prove t/db_dependent/Koha/REST/Plugin/Auth/IdP.t => SUCCESS: Tests pass! 3. Have a valid OAuth... 4. Enable Staff auto-register 5. Login with an external IdP on the staff interface => SUCCESS: It gets registered! Note: it will probably lack permissions to access the staff interface, but you can check on the DB it got registered. 6. Sign off :-D Sponsored-by: ByWater Solutions Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> All working well in testing.. permissions mapping could be fun but is for a followup bug I reckon. (In reply to Martin Renvoize (ashimema) from comment #11) > All working well in testing.. permissions mapping could be fun but is for a > followup bug I reckon. Agreed. That one is scarier... Created attachment 185244 [details] [review] Bug 37711: DB update Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Created attachment 185245 [details] [review] Bug 37711: DBIC schema Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Created attachment 185246 [details] [review] Bug 37711: API changes This patch makes the API representation of the identity providers domains match the new metadata. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Created attachment 185247 [details] [review] Bug 37711: Domains CRUD update This patch adapts the `Identity provider domains` CRUD page to handle the new configuration options. To test: 1. Have an IdP with some domains set. Make sure there's at least one domain with auto-register enabled and one with it disabled. 2. Apply this patches 3. Run: $ ktd --shell k$ updatedatabase => SUCCESS: Updates successfully 4. Run: k$ yarn build 5. Refresh the IdP domains page => SUCCESS: The domains table shows both OPAC and staff auto-register options. => SUCCESS: The staff auto-register is disabled for both domains => SUCCESS: The OPAC auto-register matches what was set for each domain regarding auto-register (remember that before this patchset, auto-register only works for the OPAC). 6. Play with editing/adding/removing domain configurations => SUCCESS: Things work as expected, values are persisted on the DB correctly. 7. Sign off :-D Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Created attachment 185248 [details] [review] Bug 37711: Add support for staff interface auto-register on IdP Before this patches, only OPAC auto-registration at login using OAuth2/OIDC IdPs was allowed. This patch makes the staff interface to be able to auto-register new users. On doing it, I had to track down the possible values for the `interface` parameter in the case of the staff interface. Koha::Template::Plugin::AuthClient uses 'staff' internally so I sticked with it. The whole area needs more param validation and exceptions to avoid mistakes for not knowing the valid values. I added some safeguards on the Koha::REST::Plugin::Auth::IdP helpers. They get tested on the added tests. To test: 1. Apply this patch 2. Run: $ prove t/db_dependent/Koha/REST/Plugin/Auth/IdP.t => SUCCESS: Tests pass! 3. Have a valid OAuth... 4. Enable Staff auto-register 5. Login with an external IdP on the staff interface => SUCCESS: It gets registered! Note: it will probably lack permissions to access the staff interface, but you can check on the DB it got registered. 6. Sign off :-D Sponsored-by: ByWater Solutions Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Rebased. Hmm.. It's been a while.. I'm going to upgrade my SO to a straight QA as there's seems to be hardly anyone with the knowledge to dig in and QA here. (In reply to Martin Renvoize (ashimema) from comment #19) > Hmm.. It's been a while.. I'm going to upgrade my SO to a straight QA as > there's seems to be hardly anyone with the knowledge to dig in and QA here. It's been tough to make this one a priority since my libraries just need self-registration via the OPAC, but I do have the knowledge... I'll take a little look too just to double-check... My only real concern was the permissions thing, but I think that's left out here, fortunately. Failing QA, as there's an inconsistency between the atomic update and kohastructure.sql Comment on attachment 185244 [details] [review] Bug 37711: DB update Review of attachment 185244 [details] [review]: ----------------------------------------------------------------- ::: installer/data/mysql/atomicupdate/bug_37711.pl @@ +22,5 @@ > + if ( !column_exists( 'identity_provider_domains', 'auto_register_staff' ) ) { > + $dbh->do( > + q{ > + ALTER TABLE identity_provider_domains > + ADD COLUMN `auto_register_staff` tinyint(1) NOT NULL DEFAULT 0 COMMENT 'Allow user auto register (OPAC)' The comment here should be: 'Allow user auto register (Staff interface)' Comment on attachment 185247 [details] [review] Bug 37711: Domains CRUD update Review of attachment 185247 [details] [review]: ----------------------------------------------------------------- ::: koha-tmpl/intranet-tmpl/prog/en/modules/admin/identity_provider_domains.tt @@ +322,5 @@ > </div> > [% END %] > > + <div id="toolbar" class="btn-toolbar"> > + <a class="btn btn-default" id="new_identity_provider_domain" href="/cgi-bin/koha/admin/identity_providers.pl?domain_ops=1&identity_provider_id=[%- identity_provider_id | html -%]&op=add_form" I thought that we were using & instead of & these days, but not really an issue... Sorry I was going to keep testing but I've got caught up in other things... Failed QA for a few more things: - If you select "Auto register" "Yes" on http://localhost:8081/cgi-bin/koha/admin/identity_providers.pl?op=add_form, and then you go to review the domain for that IdP, it'll say "Auto register (OPAC):" "Don't allow" and "Auto register (Staff)" "Don't allow". - When viewing the "Identity provider domains for '<idp>'", there are 2 tables. One appears to be the old table format which has only 1 column "Auto register". This is the table that is populated. Beneath that table there is another one with the correct 2 "Auto register" columns, but no data is provided. (In reply to David Cook from comment #25) > - When viewing the "Identity provider domains for '<idp>'", there are 2 > tables. One appears to be the old table format which has only 1 column > "Auto register". This is the table that is populated. Beneath that table > there is another one with the correct 2 "Auto register" columns, but no data > is provided. Note that this 2nd table appears correctly when you go into edit a particular domain for an IdP, so this is probably an easy fix on the listing view page Thanks for the valuable feedback, dcook! (In reply to Tomás Cohen Arazi (tcohen) from comment #27) > Thanks for the valuable feedback, dcook! No worries. I tried 😅 (In reply to David Cook from comment #25) > Failed QA for a few more things: > > - If you select "Auto register" "Yes" on > http://localhost:8081/cgi-bin/koha/admin/identity_providers.pl?op=add_form, > and then you go to review the domain for that IdP, it'll say "Auto register > (OPAC):" "Don't allow" and "Auto register (Staff)" "Don't allow". > > - When viewing the "Identity provider domains for '<idp>'", there are 2 > tables. One appears to be the old table format which has only 1 column > "Auto register". This is the table that is populated. Beneath that table > there is another one with the correct 2 "Auto register" columns, but no data > is provided. Ooof. That's a terrible rebase :-D Created attachment 186978 [details] [review] Bug 37711: DB update Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Created attachment 186979 [details] [review] Bug 37711: DBIC schema Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Created attachment 186980 [details] [review] Bug 37711: API changes This patch makes the API representation of the identity providers domains match the new metadata. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Created attachment 186981 [details] [review] Bug 37711: Domains CRUD update This patch adapts the `Identity provider domains` CRUD page to handle the new configuration options. To test: 1. Have an IdP with some domains set. Make sure there's at least one domain with auto-register enabled and one with it disabled. 2. Apply this patches 3. Run: $ ktd --shell k$ updatedatabase => SUCCESS: Updates successfully 4. Run: k$ yarn build 5. Refresh the IdP domains page => SUCCESS: The domains table shows both OPAC and staff auto-register options. => SUCCESS: The staff auto-register is disabled for both domains => SUCCESS: The OPAC auto-register matches what was set for each domain regarding auto-register (remember that before this patchset, auto-register only works for the OPAC). 6. Play with editing/adding/removing domain configurations => SUCCESS: Things work as expected, values are persisted on the DB correctly. 7. Sign off :-D Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Created attachment 186982 [details] [review] Bug 37711: Add support for staff interface auto-register on IdP Before this patches, only OPAC auto-registration at login using OAuth2/OIDC IdPs was allowed. This patch makes the staff interface to be able to auto-register new users. On doing it, I had to track down the possible values for the `interface` parameter in the case of the staff interface. Koha::Template::Plugin::AuthClient uses 'staff' internally so I sticked with it. The whole area needs more param validation and exceptions to avoid mistakes for not knowing the valid values. I added some safeguards on the Koha::REST::Plugin::Auth::IdP helpers. They get tested on the added tests. To test: 1. Apply this patch 2. Run: $ prove t/db_dependent/Koha/REST/Plugin/Auth/IdP.t => SUCCESS: Tests pass! 3. Have a valid OAuth... 4. Enable Staff auto-register 5. Login with an external IdP on the staff interface => SUCCESS: It gets registered! Note: it will probably lack permissions to access the staff interface, but you can check on the DB it got registered. 6. Sign off :-D Sponsored-by: ByWater Solutions Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> (In reply to David Cook from comment #22) > > + ALTER TABLE identity_provider_domains > > + ADD COLUMN `auto_register_staff` tinyint(1) NOT NULL DEFAULT 0 COMMENT 'Allow user auto register (OPAC)' > > The comment here should be: > 'Allow user auto register (Staff interface)' Fixed inline. Good catch! > > + <a class="btn btn-default" id="new_identity_provider_domain" href="/cgi-bin/koha/admin/identity_providers.pl?domain_ops=1&identity_provider_id=[%- identity_provider_id | html -%]&op=add_form" > > I thought that we were using & instead of & these days, but not really > an issue... The file is full of those. Maybe a separate bug to review how we build URLs globally and add a check somewhere? > - If you select "Auto register" "Yes" on > http://localhost:8081/cgi-bin/koha/admin/identity_providers.pl?op=add_form, > and then you go to review the domain for that IdP, it'll say "Auto register > (OPAC):" "Don't allow" and "Auto register (Staff)" "Don't allow". > > - When viewing the "Identity provider domains for '<idp>'", there are 2 > tables. One appears to be the old table format which has only 1 column > "Auto register". This is the table that is populated. Beneath that table > there is another one with the correct 2 "Auto register" columns, but no data > is provided. Bad rebase. Solved. Created attachment 187000 [details] [review] Bug 37711: Domains CRUD update This patch adapts the `Identity provider domains` CRUD page to handle the new configuration options. To test: 1. Have an IdP with some domains set. Make sure there's at least one domain with auto-register enabled and one with it disabled. 2. Apply this patches 3. Run: $ ktd --shell k$ updatedatabase => SUCCESS: Updates successfully 4. Run: k$ yarn build 5. Refresh the IdP domains page => SUCCESS: The domains table shows both OPAC and staff auto-register options. => SUCCESS: The staff auto-register is disabled for both domains => SUCCESS: The OPAC auto-register matches what was set for each domain regarding auto-register (remember that before this patchset, auto-register only works for the OPAC). 6. Play with editing/adding/removing domain configurations => SUCCESS: Things work as expected, values are persisted on the DB correctly. 7. Sign off :-D Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Created attachment 187001 [details] [review] Bug 37711: Add support for staff interface auto-register on IdP Before this patches, only OPAC auto-registration at login using OAuth2/OIDC IdPs was allowed. This patch makes the staff interface to be able to auto-register new users. On doing it, I had to track down the possible values for the `interface` parameter in the case of the staff interface. Koha::Template::Plugin::AuthClient uses 'staff' internally so I sticked with it. The whole area needs more param validation and exceptions to avoid mistakes for not knowing the valid values. I added some safeguards on the Koha::REST::Plugin::Auth::IdP helpers. They get tested on the added tests. To test: 1. Apply this patch 2. Run: $ prove t/db_dependent/Koha/REST/Plugin/Auth/IdP.t => SUCCESS: Tests pass! 3. Have a valid OAuth... 4. Enable Staff auto-register 5. Login with an external IdP on the staff interface => SUCCESS: It gets registered! Note: it will probably lack permissions to access the staff interface, but you can check on the DB it got registered. 6. Sign off :-D Sponsored-by: ByWater Solutions Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Marking "Failed QA". When adding an identity provider for the first time via http://localhost:8081/cgi-bin/koha/admin/identity_providers.pl?op=add_form there is only one "Auto register" option. If you select "Yes", when you go to review the domains for that IdP, you'll see that it says "No" for both "Auto register (OPAC)" and "Auto register (Staff)". -- Other than that... I think it's all good. Once that last bit is fixed, I think it'll be good to go. The functionality all works as expected otherwise. Created attachment 187034 [details] [review] Bug 37711: Domains CRUD update This patch adapts the `Identity provider domains` CRUD page to handle the new configuration options. To test: 1. Have an IdP with some domains set. Make sure there's at least one domain with auto-register enabled and one with it disabled. 2. Apply this patches 3. Run: $ ktd --shell k$ updatedatabase => SUCCESS: Updates successfully 4. Run: k$ yarn build 5. Refresh the IdP domains page => SUCCESS: The domains table shows both OPAC and staff auto-register options. => SUCCESS: The staff auto-register is disabled for both domains => SUCCESS: The OPAC auto-register matches what was set for each domain regarding auto-register (remember that before this patchset, auto-register only works for the OPAC). 6. Play with editing/adding/removing domain configurations => SUCCESS: Things work as expected, values are persisted on the DB correctly. 7. Sign off :-D Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Created attachment 187037 [details] [review] Bug 37711: Domains CRUD update This patch adapts the `Identity provider domains` CRUD page to handle the new configuration options. To test: 1. Have an IdP with some domains set. Make sure there's at least one domain with auto-register enabled and one with it disabled. 2. Apply this patches 3. Run: $ ktd --shell k$ updatedatabase => SUCCESS: Updates successfully 4. Run: k$ yarn build 5. Refresh the IdP domains page => SUCCESS: The domains table shows both OPAC and staff auto-register options. => SUCCESS: The staff auto-register is disabled for both domains => SUCCESS: The OPAC auto-register matches what was set for each domain regarding auto-register (remember that before this patchset, auto-register only works for the OPAC). 6. Play with editing/adding/removing domain configurations => SUCCESS: Things work as expected, values are persisted on the DB correctly. 7. Sign off :-D Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Created attachment 187038 [details] [review] Test patch description Created attachment 187039 [details] [review] Test patch description 2 Created attachment 187040 [details] [review] Test patch description 1 Created attachment 187041 [details] [review] Test patch description 2 Created attachment 187042 [details] [review] Test patch description 3 Created attachment 187043 [details] [review] Debug test I fixed the issue, @dcook. Sorry, for the noise, I decided to fix the 'Network error' git-bz was returning and used this bug to debug it. Created attachment 187068 [details] [review] Bug 37711: DB update Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: David Cook <dcook@prosentient.com.au> Created attachment 187069 [details] [review] Bug 37711: DBIC schema Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: David Cook <dcook@prosentient.com.au> Created attachment 187070 [details] [review] Bug 37711: API changes This patch makes the API representation of the identity providers domains match the new metadata. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: David Cook <dcook@prosentient.com.au> Created attachment 187071 [details] [review] Bug 37711: Add support for staff interface auto-register on IdP Before this patches, only OPAC auto-registration at login using OAuth2/OIDC IdPs was allowed. This patch makes the staff interface to be able to auto-register new users. On doing it, I had to track down the possible values for the `interface` parameter in the case of the staff interface. Koha::Template::Plugin::AuthClient uses 'staff' internally so I sticked with it. The whole area needs more param validation and exceptions to avoid mistakes for not knowing the valid values. I added some safeguards on the Koha::REST::Plugin::Auth::IdP helpers. They get tested on the added tests. To test: 1. Apply this patch 2. Run: $ prove t/db_dependent/Koha/REST/Plugin/Auth/IdP.t => SUCCESS: Tests pass! 3. Have a valid OAuth... 4. Enable Staff auto-register 5. Login with an external IdP on the staff interface => SUCCESS: It gets registered! Note: it will probably lack permissions to access the staff interface, but you can check on the DB it got registered. 6. Sign off :-D Sponsored-by: ByWater Solutions Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: David Cook <dcook@prosentient.com.au> Created attachment 187072 [details] [review] Bug 37711: Domains CRUD update This patch adapts the `Identity provider domains` CRUD page to handle the new configuration options. To test: 1. Have an IdP with some domains set. Make sure there's at least one domain with auto-register enabled and one with it disabled. 2. Apply this patches 3. Run: $ ktd --shell k$ updatedatabase => SUCCESS: Updates successfully 4. Run: k$ yarn build 5. Refresh the IdP domains page => SUCCESS: The domains table shows both OPAC and staff auto-register options. => SUCCESS: The staff auto-register is disabled for both domains => SUCCESS: The OPAC auto-register matches what was set for each domain regarding auto-register (remember that before this patchset, auto-register only works for the OPAC). 6. Play with editing/adding/removing domain configurations => SUCCESS: Things work as expected, values are persisted on the DB correctly. 7. Sign off :-D Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: David Cook <dcook@prosentient.com.au> Looking good. Thanks, Tomas! There is a problem here when I try to updatedatabase:
{UNKNOWN}: DBIx::Class::ResultSource::column_info(): No such column auto_register at /kohadevbox/koha/Koha/Schema/Result/IdentityProviderDomain.pm line 222
Compilation failed in require at /usr/share/perl5/Class/C3/Componentised.pm line 146. at /usr/share/perl5/Class/C3/Componentised.pm line 151
Compilation failed in require at /kohadevbox/koha/C4/Installer.pm line 30.
BEGIN failed--compilation aborted at /kohadevbox/koha/C4/Installer.pm line 30.
Compilation failed in require at /kohadevbox/koha/installer/data/mysql/updatedatabase.pl line 41.
BEGIN failed--compilation aborted at /kohadevbox/koha/installer/data/mysql/updatedatabase.pl line 41.
(In reply to Lucas Gass (lukeg) from comment #54) > There is a problem here when I try to updatedatabase: > > {UNKNOWN}: DBIx::Class::ResultSource::column_info(): No such column > auto_register at > /kohadevbox/koha/Koha/Schema/Result/IdentityProviderDomain.pm line 222 > Compilation failed in require at /usr/share/perl5/Class/C3/Componentised.pm > line 146. at /usr/share/perl5/Class/C3/Componentised.pm line 151 > Compilation failed in require at /kohadevbox/koha/C4/Installer.pm line 30. > BEGIN failed--compilation aborted at /kohadevbox/koha/C4/Installer.pm line > 30. > Compilation failed in require at > /kohadevbox/koha/installer/data/mysql/updatedatabase.pl line 41. > BEGIN failed--compilation aborted at > /kohadevbox/koha/installer/data/mysql/updatedatabase.pl line 41. That's because you skipped the DBIx::Class schema update from the second patch. I know it is a chicken-egg problem because of the boolean attributes... Now I'm trying to remember how I updated the database... I might've done a reset_all which would use the kohastructure.sql I think, although I thought that I tried an upgradedatabase.pl as well... (In reply to David Cook from comment #56) > Now I'm trying to remember how I updated the database... I might've done a > reset_all which would use the kohastructure.sql I think, although I thought > that I tried an upgradedatabase.pl as well... I just re-tested with a fresh main and the following works: 1. git bz apply 37711 2. sudo koha-upgrade-schema kohadev Upgrading database schema for kohadev DEV atomic update /kohadevbox/koha/installer/data/mysql/atomicupdate/bug_37711.pl [22:20:32]: Bug 37711 - Allow setting auto-register per interface (identity providers) Added column 'identity_provider_domains.auto_register_opac' Added column 'identity_provider_domains.auto_register_staff' Removed column 'identity_provider_domains.auto_register' Oh... but then that got me thinking... If you apply the patches, restart Koha, but then rely on the web installer... this won't work. Going to http://localhost:8081/ will yield a 500 error with the following in the plack-error.log: Template process failed: undef error - DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Unknown column 'domains.auto_register_opac' in 'field list' at /kohadevbox/koha/Koha/Objects.pm line 319 Template process failed: undef error - DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Unknown column 'domains.auto_register_opac' in 'field list' at /kohadevbox/koha/Koha/Objects.pm line 319 -- While the Debian packages are the preferred way to go, I think that we are still supporting the web installer, and these patches would break the web installer it seems. The only solution I can think of would be to change "use Koha::Auth::Identity::Providers;" to "require Koha::Auth::Identity::Providers;" and move it into the try/catch block with "Koha::Auth::Identity::Providers->search". When using the web installer, it would fail, but it should fail gracefully. Gracefully in the sense that they're able to complete the web installer and maybe have a message saying they need to restart for the upgraded libraries to come into effect. (In reply to David Cook from comment #58) > The only solution I can think of would be... Hmm maybe overly optimistic because I change that and it still fails with a 500 error. There's no stack trace so it's not clear where this code is being called. Doing a bit of grepping, and it looks like probably a few other places, since it looks like it's the "->next" call which is triggering the error. Maybe Koha/Template/Plugin/AuthClient.pm, Koha/Auth/Client.pm, and/or somewhere else. Created attachment 187848 [details] [review] Bug 37711: (follow-up) Fix AuthClient plugin database upgrade handling The AuthClient template plugin was causing 500 errors during database upgrades when the identity_providers schema was out of sync. The plugin tried to query the new 'auto_register_opac' column before the database schema was updated, creating a chicken-egg problem. This patch wraps the database query in Try::Tiny to handle schema mismatches gracefully during upgrades, allowing the upgrade process to continue without crashing the authentication interface. Test plan: 1. On main, apply all bug 37711 patches BUT THIS ONE 2. Simulate an upgrade by: * Edit Koha.pm so it points to the next version * Move the atomicupdate file to the right number in db_revs 3. Restart everything: $ ktd --shell k$ restart_all 4. Access http://kohadev-intra.localhost => FAIL: You get a 500! With a stack trace! 5. Apply this patch 6. Repeat 3 and 4 => SUCCESS: No 500 error, redirects to installer 7. Proceed with the upgrade: => SUCCESS: It works as it should 8. Run tests: k$ prove -v t/db_dependent/Template/Plugin/AuthClient.t => SUCCESS: All tests pass 9. Sign off :-D Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io> (In reply to David Cook from comment #59) > (In reply to David Cook from comment #58) > > The only solution I can think of would be... > > Hmm maybe overly optimistic because I change that and it still fails with a > 500 error. There's no stack trace so it's not clear where this code is being > called. I submitted a patch that addresses the chicken-egg problem. Which you identified correctly to be related to the Koha::Template::Plugin::AuthClient class (instantiating the Koha::Identity::Providers). This highlighted Koha was breaking badly if there was an error fetching the IdPs. I decided it should just warn about the situation, and move forward so wrapped it in a try/catch block. And added missing tests for the template plugin while in the area. I set it back to SO so you can give it a last try for a final QA. Really glad you caught this. Thanks! (In reply to Tomás Cohen Arazi (tcohen) from comment #61) > (In reply to David Cook from comment #59) > > (In reply to David Cook from comment #58) > > > The only solution I can think of would be... > > > > Hmm maybe overly optimistic because I change that and it still fails with a > > 500 error. There's no stack trace so it's not clear where this code is being > > called. > > I submitted a patch that addresses the chicken-egg problem. Which you > identified correctly to be related to the Koha::Template::Plugin::AuthClient > class (instantiating the Koha::Identity::Providers). > > > This highlighted Koha was breaking badly if there was an error fetching the > IdPs. I decided it should just warn about the situation, and move forward so > wrapped it in a try/catch block. And added missing tests for the template > plugin while in the area. > > I set it back to SO so you can give it a last try for a final QA. > > Really glad you caught this. Thanks! Apologies for the delay in responding. Life's been a bit nuts. The additional patch looks good at a glance. I applied the patch and manually triggered the web installer and that worked well. Created attachment 188619 [details] [review] Bug 37711: (follow-up) Fix AuthClient plugin database upgrade handling The AuthClient template plugin was causing 500 errors during database upgrades when the identity_providers schema was out of sync. The plugin tried to query the new 'auto_register_opac' column before the database schema was updated, creating a chicken-egg problem. This patch wraps the database query in Try::Tiny to handle schema mismatches gracefully during upgrades, allowing the upgrade process to continue without crashing the authentication interface. Test plan: 1. On main, apply all bug 37711 patches BUT THIS ONE 2. Simulate an upgrade by: * Edit Koha.pm so it points to the next version * Move the atomicupdate file to the right number in db_revs 3. Restart everything: $ ktd --shell k$ restart_all 4. Access http://kohadev-intra.localhost => FAIL: You get a 500! With a stack trace! 5. Apply this patch 6. Repeat 3 and 4 => SUCCESS: No 500 error, redirects to installer 7. Proceed with the upgrade: => SUCCESS: It works as it should 8. Run tests: k$ prove -v t/db_dependent/Template/Plugin/AuthClient.t => SUCCESS: All tests pass 9. Sign off :-D Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io> Signed-off-by: David Cook <dcook@prosentient.com.au> Thanks for your patience, Tomas, and thanks for the patches! Nice work everyone! Pushed to main for 25.11 |