I'm really struggling to describe this issue even though I can happily replicate it with customer data... and the fix is clear and obvious. When adding, editing a borrower if a patron attribute type has a class associated with it (with a corresponding PA_CLASS AV value or otherwise), then it should appear grouped inside a fieldset with the class associated with it. However, sometimes that is not the case.. narrowing down when it happens is aluding me :(. The fix is however clear; in members/memberentry.pl we refer to $attr_type via class methods in most places but treat it like a bare hashref for the class case. Patch to follow.
Created attachment 115110 [details] [review] Bug 27420: Use object accessor for $attr_type->class() We introduced a bug in the patron attribute forms with bug 5161. Test plan 1/ Create two PA_CLASS authorized values 2/ Create two corresponding patron attribute types referencing the above classes. 3/ Edit a patron, both attributes should appear within their own fieldsets at the bottom of the member entry form. 4/ Set a value for the first of the two patron attributes and save 5/ Edit the patron again, note that the first attribute no longer resides within it's own fieldset 6/ Apply the patch 7/ Edit the patron again, note that the first attribute now resides inside it's own fieldset again 8/ Signoff
Created attachment 115114 [details] [review] Bug 27420: Use object accessor for $attr_type->class() We introduced a bug in the patron attribute forms with bug 5161. Test plan 1/ Create two PA_CLASS authorized values 2/ Create two corresponding patron attribute types referencing the above classes. 3/ Edit a patron, both attributes should appear within their own fieldsets at the bottom of the member entry form. 4/ Set a value for the first of the two patron attributes and save 5/ Edit the patron again, note that the first attribute no longer resides within it's own fieldset 6/ Apply the patch 7/ Edit the patron again, note that the first attribute now resides inside it's own fieldset again 8/ Signoff Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This works well and I am passing QA, but there is some other oddity as the entries change sequence every time you reload the page. Filed as: bug 27454
Created attachment 115223 [details] [review] Bug 27420: Use object accessor for $attr_type->class() We introduced a bug in the patron attribute forms with bug 5161. Test plan 1/ Create two PA_CLASS authorized values 2/ Create two corresponding patron attribute types referencing the above classes. 3/ Edit a patron, both attributes should appear within their own fieldsets at the bottom of the member entry form. 4/ Set a value for the first of the two patron attributes and save 5/ Edit the patron again, note that the first attribute no longer resides within it's own fieldset 6/ Apply the patch 7/ Edit the patron again, note that the first attribute now resides inside it's own fieldset again 8/ Signoff Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Pushed to master for 21.05, thanks to everybody involved!
Pushed to 20.11.x for 20.11.02
Pushed to 20.05.x for 20.05.08
Missing dependencies for 19.11.x, shouldn't be affected, no backport.