Created attachment 128778 [details] [review] Bug 29741: Unit tests Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 128779 [details] [review] Bug 29741: Add Koha::Patron->safe_to_delete This patchset adds a handy method for checking if a patron meets the conditions to be deleted. This conditions are: - Has no linked guarantees - Has no pending debts - Has no current checkouts - Is not the system-configured anonymous user To test: 1. Apply the unit tests patch 2. Run: $ kshell k$ prove t/db_dependent/Koha/Patron.t => FAIL: Of course heh 3. Apply this patch 4. Repeat 2 => SUCCESS: Tests pass, conditions are validated and the right string is returned on each case 5. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 128784 [details] [review] Bug 29741: (follow-up) Make DELETE /patrons use the new validation method This patch adapts the route so it uses the newly introduced Koha::Patron->safe_to_delete method. To test: 1. Run: $ kshell k$ prove t/db_dependent/api/v1/patrons.t => SUCCESS: Tests pass 2. Apply this patch 3. Repeat 1 => SUCCESS: Tests still pass! 4. Sign off :-D Note: There's a trivial behavior change, in which the 'anonymous patron' use case is caugh eariler than the ->delete call. I left the exception catch block just in case, who knows :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Sorry dude, not 100% sure of the construct here... I feel like 'safe_to_delete' should return a Boolean given it's method name? Perhaps a boolean in scalar context and a Boolean + hash or array of errors as the second slot of an array in list context?
(In reply to Martin Renvoize from comment #4) > Sorry dude, not 100% sure of the construct here... I feel like > 'safe_to_delete' should return a Boolean given it's method name? > > Perhaps a boolean in scalar context and a Boolean + hash or array of errors > as the second slot of an array in list context? Maybe a Koha::Validation object that validates to a bool, and carries messages in it?
(In reply to Tomás Cohen Arazi from comment #5) > (In reply to Martin Renvoize from comment #4) > > Sorry dude, not 100% sure of the construct here... I feel like > > 'safe_to_delete' should return a Boolean given it's method name? > > > > Perhaps a boolean in scalar context and a Boolean + hash or array of errors > > as the second slot of an array in list context? > > Maybe a Koha::Validation object that validates to a bool, and carries > messages in it? I replicated Koha::Item's to limit the conflict surface, but...hey... Hehe
Created attachment 128814 [details] [review] Bug 29741: Unit tests Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: David Nind <david@davidnind.com>
Created attachment 128815 [details] [review] Bug 29741: Add Koha::Patron->safe_to_delete This patchset adds a handy method for checking if a patron meets the conditions to be deleted. This conditions are: - Has no linked guarantees - Has no pending debts - Has no current checkouts - Is not the system-configured anonymous user To test: 1. Apply the unit tests patch 2. Run: $ kshell k$ prove t/db_dependent/Koha/Patron.t => FAIL: Of course heh 3. Apply this patch 4. Repeat 2 => SUCCESS: Tests pass, conditions are validated and the right string is returned on each case 5. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: David Nind <david@davidnind.com>
Created attachment 128816 [details] [review] Bug 29741: (follow-up) Make DELETE /patrons use the new validation method This patch adapts the route so it uses the newly introduced Koha::Patron->safe_to_delete method. To test: 1. Run: $ kshell k$ prove t/db_dependent/api/v1/patrons.t => SUCCESS: Tests pass 2. Apply this patch 3. Repeat 1 => SUCCESS: Tests still pass! 4. Sign off :-D Note: There's a trivial behavior change, in which the 'anonymous patron' use case is caugh eariler than the ->delete call. I left the exception catch block just in case, who knows :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: David Nind <david@davidnind.com>
I've signed this off, but feel free to change the status if more work is still required (comments 4, 5 and 6).
(In reply to Tomás Cohen Arazi from comment #6) > (In reply to Tomás Cohen Arazi from comment #5) > > (In reply to Martin Renvoize from comment #4) > > > Sorry dude, not 100% sure of the construct here... I feel like > > > 'safe_to_delete' should return a Boolean given it's method name? > > > > > > Perhaps a boolean in scalar context and a Boolean + hash or array of errors > > > as the second slot of an array in list context? > > > > Maybe a Koha::Validation object that validates to a bool, and carries > > messages in it? > > I replicated Koha::Item's to limit the conflict surface, but...hey... Hehe I should have read more code for context, happy to stick with this as there's a precidence in Koha::Item.. I thought I'd seen something somewhere but couldn't place it. In the transfers work I threw exceptions and allowed a force option to be passed, but the use case isn't the same. I'd love to see us settle on something consistent.
(In reply to Martin Renvoize from comment #11) > (In reply to Tomás Cohen Arazi from comment #6) > > (In reply to Tomás Cohen Arazi from comment #5) > > > (In reply to Martin Renvoize from comment #4) > > > > Sorry dude, not 100% sure of the construct here... I feel like > > > > 'safe_to_delete' should return a Boolean given it's method name? > > > > > > > > Perhaps a boolean in scalar context and a Boolean + hash or array of errors > > > > as the second slot of an array in list context? > > > > > > Maybe a Koha::Validation object that validates to a bool, and carries > > > messages in it? > > > > I replicated Koha::Item's to limit the conflict surface, but...hey... Hehe > > I should have read more code for context, happy to stick with this as > there's a precidence in Koha::Item.. I thought I'd seen something somewhere > but couldn't place it. In the transfers work I threw exceptions and allowed > a force option to be passed, but the use case isn't the same. I'd love to > see us settle on something consistent. I filed bug 29746, and provided an implementation. If I get feedback on that, I can re-do this using that which will be much cleaner. It could be done on a follow-up bug if required, and definitely should cover Koha::Item->safe_to_delete as well.
Created attachment 128994 [details] [review] Bug 29741: Unit tests Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Created attachment 128995 [details] [review] Bug 29741: Add Koha::Patron->safe_to_delete This patchset adds a handy method for checking if a patron meets the conditions to be deleted. This conditions are: - Has no linked guarantees - Has no pending debts - Has no current checkouts - Is not the system-configured anonymous user To test: 1. Apply the unit tests patch 2. Run: $ kshell k$ prove t/db_dependent/Koha/Patron.t => FAIL: Of course heh 3. Apply this patch 4. Repeat 2 => SUCCESS: Tests pass, conditions are validated and the right string is returned on each case 5. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Created attachment 128996 [details] [review] Bug 29741: (follow-up) Make DELETE /patrons use the new validation method This patch adapts the route so it uses the newly introduced Koha::Patron->safe_to_delete method. To test: 1. Run: $ kshell k$ prove t/db_dependent/api/v1/patrons.t => SUCCESS: Tests pass 2. Apply this patch 3. Repeat 1 => SUCCESS: Tests still pass! 4. Sign off :-D Note: There's a trivial behavior change, in which the 'anonymous patron' use case is caugh eariler than the ->delete call. I left the exception catch block just in case, who knows :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Pushed to master for 22.05, thanks to everybody involved [U+1F984]
Pushed to 21.11.x for 21.11.02
Backported as part of a combo with 29018. I'd rather not leave 21.11 in a half-finished state for this issue.
Enhancement, not pushed to 21.05.x