Summary: | Need a better way of looping through smart-rules ( circ table ) columns | ||
---|---|---|---|
Product: | Koha | Reporter: | Lucas Gass (lukeg) <lucas> |
Component: | Circulation | Assignee: | Emily Lamancusa (emlam) <emily.lamancusa> |
Status: | RESOLVED FIXED | QA Contact: | Martin Renvoize (ashimema) <martin.renvoize> |
Severity: | minor | ||
Priority: | P5 - low | CC: | emily.lamancusa, gmcharlt, kyle.m.hall, martin.renvoize |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: |
24.11.00
|
|
Circulation function: | |||
Attachments: |
Bug 36716: Do special processing based on input id, not column index
Bug 36716: Do special processing based on input id, not column index Bug 36716: Do special processing based on input id, not column index |
Description
Lucas Gass (lukeg)
2024-04-29 15:43:15 UTC
+1 for this! Commit c654932f0c376b2b619c9bd4550aab0adf9acdab from bug 8367 did something like that for the holds pickup period - checking the input id rather than the index. Taking a stab at this using that method... I'm also changing this to a bug rather than an enhancement, because similar bugs keep cropping up (I'm seeing at least one, with no automatic renewal after (hard limit) again, in main currently). Created attachment 170214 [details] [review] Bug 36716: Do special processing based on input id, not column index When a user clicks "Edit" ( .editrule ) we use JavaScript to loop through each of the columns in the table to copy the appropriate values into the input fields. Fields that need special processing are identified by the column index, which can lead to problems when the index varies between Koha versions or columns are shown/hidden based on syspref settings. In the current main, there is at least one such bug causing the value for "no automatic renewal before" not to propagate, but to get silently saved in the "no automatic renewal before (hard limit)" field instead. Identifying fields for special processing based on input id rather than index should fix the above issue and avoid similar regressions. To test: 1. Create a circulation rule that has: a) a value (such as 30) in the column "No automatic renewal after" b) no value in the column "No automatic renewal after (hard limit)" 2. Click the button to edit the circulation rule from step 1 --> The text field for "No automatic renewal after" is blank 3. Save the rule without making any changes --> "No automatic renewal after" is now blank for this rule, but "No automatic renewal after (hard limit)" has a date in it 4. Apply patch 5. Repeat steps 1-3 --> "No automatic renewal after" and "No automatic renewal after (hard limit)" now preserve their values correctly 6. Create a circulation rule that has a non-default value in every field 7. Edit the circulation rule from step 6 --> Confirm that all values are copied to the edit fields correctly 8. Save the rule without making any changes --> Confirm that the rule saved correctly 9. Create a circulation rule, leaving the following columns blank: "Current checkouts allowed" "Current on-site checkouts allowed" "Holds allowed (total)" "Holds allowed (daily)" "Holds per record (count)" --> The above columns should display as "Unlimited" 10. Edit the rule from step 9 --> The input fields for the above columns should be blank 11. Save the rule without making any changes --> The above fields should still display as "Unlimited" Created attachment 170233 [details] [review] Bug 36716: Do special processing based on input id, not column index When a user clicks "Edit" ( .editrule ) we use JavaScript to loop through each of the columns in the table to copy the appropriate values into the input fields. Fields that need special processing are identified by the column index, which can lead to problems when the index varies between Koha versions or columns are shown/hidden based on syspref settings. In the current main, there is at least one such bug causing the value for "no automatic renewal before" not to propagate, but to get silently saved in the "no automatic renewal before (hard limit)" field instead. Identifying fields for special processing based on input id rather than index should fix the above issue and avoid similar regressions. To test: 1. Create a circulation rule that has: a) a value (such as 30) in the column "No automatic renewal after" b) no value in the column "No automatic renewal after (hard limit)" 2. Click the button to edit the circulation rule from step 1 --> The text field for "No automatic renewal after" is blank 3. Save the rule without making any changes --> "No automatic renewal after" is now blank for this rule, but "No automatic renewal after (hard limit)" has a date in it 4. Apply patch 5. Repeat steps 1-3 --> "No automatic renewal after" and "No automatic renewal after (hard limit)" now preserve their values correctly 6. Create a circulation rule that has a non-default value in every field 7. Edit the circulation rule from step 6 --> Confirm that all values are copied to the edit fields correctly 8. Save the rule without making any changes --> Confirm that the rule saved correctly 9. Create a circulation rule, leaving the following columns blank: "Current checkouts allowed" "Current on-site checkouts allowed" "Holds allowed (total)" "Holds allowed (daily)" "Holds per record (count)" --> The above columns should display as "Unlimited" 10. Edit the rule from step 9 --> The input fields for the above columns should be blank 11. Save the rule without making any changes --> The above fields should still display as "Unlimited" Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> Thanks, Emily! Created attachment 170533 [details] [review] Bug 36716: Do special processing based on input id, not column index When a user clicks "Edit" ( .editrule ) we use JavaScript to loop through each of the columns in the table to copy the appropriate values into the input fields. Fields that need special processing are identified by the column index, which can lead to problems when the index varies between Koha versions or columns are shown/hidden based on syspref settings. In the current main, there is at least one such bug causing the value for "no automatic renewal before" not to propagate, but to get silently saved in the "no automatic renewal before (hard limit)" field instead. Identifying fields for special processing based on input id rather than index should fix the above issue and avoid similar regressions. To test: 1. Create a circulation rule that has: a) a value (such as 30) in the column "No automatic renewal after" b) no value in the column "No automatic renewal after (hard limit)" 2. Click the button to edit the circulation rule from step 1 --> The text field for "No automatic renewal after" is blank 3. Save the rule without making any changes --> "No automatic renewal after" is now blank for this rule, but "No automatic renewal after (hard limit)" has a date in it 4. Apply patch 5. Repeat steps 1-3 --> "No automatic renewal after" and "No automatic renewal after (hard limit)" now preserve their values correctly 6. Create a circulation rule that has a non-default value in every field 7. Edit the circulation rule from step 6 --> Confirm that all values are copied to the edit fields correctly 8. Save the rule without making any changes --> Confirm that the rule saved correctly 9. Create a circulation rule, leaving the following columns blank: "Current checkouts allowed" "Current on-site checkouts allowed" "Holds allowed (total)" "Holds allowed (daily)" "Holds per record (count)" --> The above columns should display as "Unlimited" 10. Edit the rule from step 9 --> The input fields for the above columns should be blank 11. Save the rule without making any changes --> The above fields should still display as "Unlimited" Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Massive Dev quality of life improvement here.. thanks Lucas.. no idea why we haven't done this before now! (In reply to Martin Renvoize from comment #6) > Massive Dev quality of life improvement here.. thanks Lucas.. no idea why we > haven't done this before now! I agree! One question, why not update these? (visible above one of the deleted lines in the patch): if ( i == 0 || i == 1 ) { Pushed for 24.11! Well done everyone, thank you! (In reply to Katrin Fischer from comment #8) > One question, why not update these? (visible above one of the deleted lines > in the patch): > > if ( i == 0 || i == 1 ) { Never got a reply. Dropping. |