See bug 21648 comment 17. Suggestion is to keep the non-repeatable patron's attribute from the patron we selected instead of raising a blocking error.
Created attachment 125070 [details] [review] Bug 29059: Keep non-repeatable attribute from patron to preserve when merging See bug 21648 comment 17. Suggestion is to keep the non-repeatable patron's attribute from the patron we selected instead of raising a blocking error. A side-effect will be that when several patrons are merged, the non-repeatable attribute from the first one will be kept, which can result in unexpected result if the original patron does not have the attribute defined.
It would be preferable if we are given the setting in both and could choose which to use. Also, it is more likely that the more recent record will have up-to-date information. Keeping the first one is not necessarily the best option. But it would be preferred to review the different entries and select the correct one.
Then we need the full UI suggested by bug 21648 and this bug report can be closed.
Created attachment 131126 [details] [review] Bug 29059: Keep non-repeatable attribute from patron to preserve when merging See bug 21648 comment 17. Suggestion is to keep the non-repeatable patron's attribute from the patron we selected instead of raising a blocking error. A side-effect will be that when several patrons are merged, the non-repeatable attribute from the first one will be kept, which can result in unexpected result if the original patron does not have the attribute defined. Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Thanks, Jonathan! The enhancement in bug 21648 would be great, but this is a perfectly workable solution for the time-being!
Created attachment 132485 [details] [review] Bug 29059: Keep non-repeatable attribute from patron to preserve when merging See bug 21648 comment 17. Suggestion is to keep the non-repeatable patron's attribute from the patron we selected instead of raising a blocking error. A side-effect will be that when several patrons are merged, the non-repeatable attribute from the first one will be kept, which can result in unexpected result if the original patron does not have the attribute defined. Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Pushed to master for 22.05, thanks to everybody involved [U+1F984]