In the case of non-repeatable attributes, if you are adding a new attribute, the check works correctly. But if you are editing an existing attribute, it fails, because it doesn't exclude it's own id from the search :-/
Created attachment 118792 [details] [review] Bug 28031: Regression tests
Created attachment 118793 [details] [review] Bug 28031: Avoid wrong exception on saving updated attribute In the case a non-repeatable attribute for a patron is being updated (its value) the routines that check the type is repeatable should exclude its own id from the search for things to work. This patch solves that. To test: 1. Apply the regression tests patch 2. Run: $ kshell k$ prove t/db_dependent/Koha/Patron/Attribute.t => FAIL: Tests explode! An unexpected exception is thrown! 3. Apply this patch 4. Repeat 2 => SUCCESS: Tests pass! 5. Sign off :-D
Created attachment 118794 [details] [review] Bug 28031: (follow-up) Retrieve type only once The current implementation of store+check_repeatable+check_unique_id notably retrieves the related Koha::Patron::Attribute::Type object three times. This can be easily solved by retrieving it once and reusing. This patch does that. This changes the signature for the helper methods. To test: 1. Run: $ kshell k$ prove t/db_dependent/Koha/Patron/Attribute.t => SUCCESS: Tests pass! 2. Apply this patch 3. Repeat 1 => SUCCESS: Tests pass! 4. Verify the old _check_repeatable method is not used anywhere $ git grep _check_repeatable => SUCCESS: It is not! 5. Verify check_unique_id is not used anywhere, so no risk changing the signature $ git grep check_unique_id => SUCCESS: It is safe to update it! 6. Sign off :-D
Created attachment 118828 [details] [review] Bug 28031: Regression tests Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 118829 [details] [review] Bug 28031: Avoid wrong exception on saving updated attribute In the case a non-repeatable attribute for a patron is being updated (its value) the routines that check the type is repeatable should exclude its own id from the search for things to work. This patch solves that. To test: 1. Apply the regression tests patch 2. Run: $ kshell k$ prove t/db_dependent/Koha/Patron/Attribute.t => FAIL: Tests explode! An unexpected exception is thrown! 3. Apply this patch 4. Repeat 2 => SUCCESS: Tests pass! 5. Sign off :-D Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 118830 [details] [review] Bug 28031: (follow-up) Retrieve type only once The current implementation of store+check_repeatable+check_unique_id notably retrieves the related Koha::Patron::Attribute::Type object three times. This can be easily solved by retrieving it once and reusing. This patch does that. This changes the signature for the helper methods. To test: 1. Run: $ kshell k$ prove t/db_dependent/Koha/Patron/Attribute.t => SUCCESS: Tests pass! 2. Apply this patch 3. Repeat 1 => SUCCESS: Tests pass! 4. Verify the old _check_repeatable method is not used anywhere $ git grep _check_repeatable => SUCCESS: It is not! 5. Verify check_unique_id is not used anywhere, so no risk changing the signature $ git grep check_unique_id => SUCCESS: It is safe to update it! 6. Sign off :-D Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 118831 [details] [review] Bug 28031: (follow-up) Clarify check methods The check methods were positioned under the 'Internal methods' section of the meodule but are used externally. It also felt strange to have a noop or die method. Instead, I propose renaming them to `repeatable_ok` and `unique_ok` and returning a boolean denoting their state.
Created attachment 118833 [details] [review] Bug 28031: (follow-up) Cache type instead of passing We should cache the 'type' instead of passing it around. That way we're not changing the signature further for external users of the methods.
Created attachment 118859 [details] [review] Bug 28031: Regression tests Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 118860 [details] [review] Bug 28031: Avoid wrong exception on saving updated attribute In the case a non-repeatable attribute for a patron is being updated (its value) the routines that check the type is repeatable should exclude its own id from the search for things to work. This patch solves that. To test: 1. Apply the regression tests patch 2. Run: $ kshell k$ prove t/db_dependent/Koha/Patron/Attribute.t => FAIL: Tests explode! An unexpected exception is thrown! 3. Apply this patch 4. Repeat 2 => SUCCESS: Tests pass! 5. Sign off :-D Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 118861 [details] [review] Bug 28031: (follow-up) Retrieve type only once The current implementation of store+check_repeatable+check_unique_id notably retrieves the related Koha::Patron::Attribute::Type object three times. This can be easily solved by retrieving it once and reusing. This patch does that. This changes the signature for the helper methods. To test: 1. Run: $ kshell k$ prove t/db_dependent/Koha/Patron/Attribute.t => SUCCESS: Tests pass! 2. Apply this patch 3. Repeat 1 => SUCCESS: Tests pass! 4. Verify the old _check_repeatable method is not used anywhere $ git grep _check_repeatable => SUCCESS: It is not! 5. Verify check_unique_id is not used anywhere, so no risk changing the signature $ git grep check_unique_id => SUCCESS: It is safe to update it! 6. Sign off :-D Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 118862 [details] [review] Bug 28031: (follow-up) Clarify check methods The check methods were positioned under the 'Internal methods' section of the meodule but are used externally. It also felt strange to have a noop or die method. Instead, I propose renaming them to `repeatable_ok` and `unique_ok` and returning a boolean denoting their state. Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 118863 [details] [review] Bug 28031: (follow-up) Cache type instead of passing We should cache the 'type' instead of passing it around. That way we're not changing the signature further for external users of the methods. Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
1. Patches applied on top of the whole tree # Failed test 'globally mandatory attributes tests' # at t/db_dependent/Koha/Patron.t line 661. # Looks like you failed 1 test of 15. t/db_dependent/Koha/Patron.t .. 7/7 # Failed test 'extended_attributes' # at t/db_dependent/Koha/Patron.t line 664. Can't locate object method "value" via package "Koha::Exceptions::Patron::MissingMandatoryExtendedAttribute" at t/db_dependent/Koha/Patron.t line 650. 2. Why Koha::Patron::Attribute->type does not look like return Koha::Patron::Attribute::Type->_new_from_dbic( $self->_result->code ); 3. Additionally I don't agree with the "cache", simply because the following code will be wrong: $attr->type($new_code)->store; my $type = $attr->type; # will get the old type
(In reply to Jonathan Druart from comment #14) > 1. > Patches applied on top of the whole tree > > # Failed test 'globally mandatory attributes tests' > # at t/db_dependent/Koha/Patron.t line 661. > # Looks like you failed 1 test of 15. > t/db_dependent/Koha/Patron.t .. 7/7 > # Failed test 'extended_attributes' > # at t/db_dependent/Koha/Patron.t line 664. > Can't locate object method "value" via package > "Koha::Exceptions::Patron::MissingMandatoryExtendedAttribute" at > t/db_dependent/Koha/Patron.t line 650. Will check now. > 2. > Why Koha::Patron::Attribute->type does not look like > > return Koha::Patron::Attribute::Type->_new_from_dbic( $self->_result->code > ); I didn't intend to change the method inline, I was tempted to, though. I thought of doing it on a separate bug, also adding the 'type' relationship so it can be followed through on embedding (API). > 3. Additionally I don't agree with the "cache", simply because the following > code will be wrong: > > $attr->type($new_code)->store; > my $type = $attr->type; # will get the old type I agree caching is not as trivial. I changed the methods signature to accept the type to avoid fetching things twice, but then Martin found some uses of the methods in a controller so it felt like changing the signature would required changes outside. Maybe an alternate patch making the param optional is a better approach? my ($self, $type) = @_; my $THE_type = $type // $self->type;
Created attachment 119377 [details] [review] Bug 28031: (QA follow-up) Adapt controllers and class This patch adapts the *memberentry.pl controllers so they pass the $type parameter when calling unique_ok. The parameter would still be retrieved from the DB if not passed, and then fetched again for reporting back errors... So it makes sense to do it once and stick with this approach. The $type parameter is made mandatory, and exceptions are thrown if missing. Tests added only for this exception situation, as the other cases are already covered in the store() tests. Bonus: this patch also fixes a mistake made on a late follow-up for bug 27857 on the tests. To test: 1. Apply this patch 2. Run: $ kshell k$ prove t/db_dependent/Koha/Patron.t \ t/db_dependent/Koha/Patron/Attribute* => SUCCESS: Tests pass! 3. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 119378 [details] [review] Bug 28031: test remove type from parameter
Created attachment 119379 [details] [review] Bug 28031: Fix patron.t
Created attachment 119380 [details] [review] Bug 28031: Remove type from parameter of *_ok methods
Created attachment 119382 [details] [review] Bug 28031: Add missing txn_begin in Attribute.t
The code looks much better without the "type" paramter passed to the *_ok methods IMO and I don't think we should care much about the additional fetch.
Pushed to master for 21.05, thanks to everybody involved!
I am having trouble with this on 20.05, I think. Any chance of a backport?
(In reply to Magnus Enger from comment #23) > I am having trouble with this on 20.05, I think. Any chance of a backport? This is depending on a several changes that are not in stable branches. What problem do you face exactly?