|
Description
Nick Clemens (kidclamp)
2019-08-21 18:50:26 UTC
Also on issuing an item? I'd like to bump this change. We were under reporting our active users because our report was counting when the lastseen date was between two dates, however we had 3000+ active users in the system missed because of the null. If the lastseen date is updated on a SIP connection or CKO, it certainly should be updated when the patron registers. Thanks! Created attachment 131657 [details] [review] Bug 23486: Set lastseen to default to current timestamp Generally, a patron is not registered without some action from the patron Defaulting the lastseen upon creation seems a reasonable way to set the initial value TO test: Apply patches Update database Create a patron Check their lastseen date Created attachment 131658 [details] [review] Bug 23486: DO NOT PUSH Schema update Hi Nick ! I get this error message when I apply the patch in a devbox : Apply? [(y)es, (n)o, (i)nteractive] y Applying: Bug 23486: Set lastseen to default to current timestamp Applying: Bug 23486: DO NOT PUSH Schema update Using index info to reconstruct a base tree... M Koha/Schema/Result/Borrower.pm Falling back to patching base and 3-way merge... Auto-merging Koha/Schema/Result/Borrower.pm CONFLICT (content): Merge conflict in Koha/Schema/Result/Borrower.pm error: Failed to merge in the changes. Patch failed at 0001 Bug 23486: DO NOT PUSH Schema update hint: Use 'git am --show-current-patch=diff' to see the failed patch When you have resolved this problem run "git bz apply --continue". If you would prefer to skip this patch, instead run "git bz apply --skip". To restore the original branch and stop patching run "git bz apply --abort". Patch left in /tmp/Bug-23486-DO-NOT-PUSH-Schema-update-1WltcW.patch I'll be happy to test it when it's fixed, thanks ! Séverine Created attachment 132222 [details] [review] Bug 23486: DO NOT PUSH Schema update Sorry Nick, I wasn't quick enough to test the first rebase, I have the same error in my DevBox :/ Apply? [(y)es, (n)o, (i)nteractive] y Applying: Bug 23486: Set lastseen to default to current timestamp Applying: Bug 23486: DO NOT PUSH Schema update Using index info to reconstruct a base tree... M Koha/Schema/Result/Borrower.pm Falling back to patching base and 3-way merge... Auto-merging Koha/Schema/Result/Borrower.pm CONFLICT (content): Merge conflict in Koha/Schema/Result/Borrower.pm error: Failed to merge in the changes. Patch failed at 0001 Bug 23486: DO NOT PUSH Schema update hint: Use 'git am --show-current-patch=diff' to see the failed patch Created attachment 134540 [details] [review] Bug 23486: DO NOT PUSH Schema update Created attachment 134547 [details] [review] Bug 23486: (follow-up) Correct Schema It seems the generated schema handles timestamp incorrectly - this will allow for testing Created attachment 134549 [details] [review] Bug 23486: Set lastseen to default to current timestamp Generally, a patron is not registered without some action from the patron Defaulting the lastseen upon creation seems a reasonable way to set the initial value TO test: Apply patches Update database Create a patron Check their lastseen date Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr> Created attachment 134550 [details] [review] Bug 23486: DO NOT PUSH Schema update Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr> Created attachment 134551 [details] [review] Bug 23486: (follow-up) Correct Schema It seems the generated schema handles timestamp incorrectly - this will allow for testing Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr> Works nice, well done Nick !! Please fix the DBIx stuff and submit it in one patch Created attachment 134963 [details] [review] Bug 23486: Set lastseen to default to current timestamp Generally, a patron is not registered without some action from the patron Defaulting the lastseen upon creation seems a reasonable way to set the initial value TO test: Apply patches Update database Create a patron Check their lastseen date Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr> Created attachment 134964 [details] [review] Bug 23486: DO NOT PUSH Schema update RM note - manual changes needed to generate There's something really odd going on here.. I don't understand why current_timestamp is coming out wrong.. though I do have vague recollections of such an issue in the past. However.. I also query.. should the column be updated to 'NOT NULL' too if we're giving it a DEFAULT? Also.. sha1 issues trying to apply the follow-up.. I think if we are going to make it 'NOT NULL' we are going to need to add a DB update, and set any currently null to the dateenrolled. That was we don't 'see' a number of patrons at upgrade Created attachment 148780 [details] [review] Bug 23486: Set lastseen to default to current timestamp Generally, a patron is not registered without some action from the patron Defaulting the lastseen upon creation seems a reasonable way to set the initial value. This patch also makes the column NOT NULL to avoid any future data issues. To handle any currently NULL, we either set them to dateenrolled, or updated_on - the latter is already NOT NULL so is the bast fallback we have (assuming patron was also seen when they were updated) TO test: Apply patches Update database Create a patron Check their lastseen date Created attachment 148781 [details] [review] Bug 23486: DO NOT PUSH - Schema Updates After applying the patch I was unable to create a new patron. I received the message, "The following fields are wrong. Please fix them." even though all the required fields were completed and no fields were being marked as incorrect. Even after filling in all the optional fields the patron could still not be created. Created attachment 149273 [details] [review] Bug 23486: Set lastseen to default to current timestamp Generally, a patron is not registered without some action from the patron Defaulting the lastseen upon creation seems a reasonable way to set the initial value. This patch also makes the column NOT NULL to avoid any future data issues. To handle any currently NULL, we either set them to dateenrolled, or updated_on - the latter is already NOT NULL so is the bast fallback we have (assuming patron was also seen when they were updated) TO test: Apply patches Update database Create a patron Check their lastseen date Created attachment 149274 [details] [review] Bug 23486: DO NOT PUSH - Schema updates Note that the fields must be manually updated after generation as generated syntax us invalid: default_value: 'current_timestamp()' First occurence: default_value: 'current_timestamp' Second occurence: default_value => \"current_timestamp", Created attachment 150119 [details] [review] Bug 23486: Set lastseen to default to current timestamp Generally, a patron is not registered without some action from the patron Defaulting the lastseen upon creation seems a reasonable way to set the initial value. This patch also makes the column NOT NULL to avoid any future data issues. To handle any currently NULL, we either set them to dateenrolled, or updated_on - the latter is already NOT NULL so is the bast fallback we have (assuming patron was also seen when they were updated) TO test: Apply patches Update database Create a patron Check their lastseen date Signed-off-by: David Nind <david@davidnind.com> Created attachment 150120 [details] [review] Bug 23486: DO NOT PUSH - Schema updates Note that the fields must be manually updated after generation as generated syntax us invalid: default_value: 'current_timestamp()' First occurence: default_value: 'current_timestamp' Second occurence: default_value => \"current_timestamp", Signed-off-by: David Nind <david@davidnind.com> Testing notes (using KTD): 1. To check the lastseen field in the database: - koha-mysql kohadev - SQL query (where XXX = borrower number for newly created patron): select * from borrowers where borrowernumber = XXX; "Generally, a patron is not registered without some action from the patron Defaulting the lastseen upon creation seems a reasonable way to set the initial value" I believe this is a wrong assumption. It works for self registrations and manual registration, but not for patron imports. Often an institution will import all their users so they can log into the OPAC when they need to, but a lot of them never will. For this use case setting the date and assuming them as active won't be correct. This is also true when migrating data using the patron import tool, also common. I think we cannot handle that on database level for this reason, we need to handle the different types of registration somehow. Also, right now documentation would be wrong: last time a patron has been seen (connected at the OPAC or staff interface) I agree with Katrin here I'm afraid. We could add patron creation to the list of actions in TrackLastPatronActivityTriggers to resolve this. I think that Katrin's suggestion is good. It lets every library then decide, do they want adding a patron to set a date to "lastseen" or not. +1 Created attachment 171829 [details] [review] Bug 23486: Add creation to TrackLasPatronActivity triggers Some libraries would like to update the last seen when a patron is created to avoid NULL values and ensure new users are marked as 'active' To test: 1 - Apply patch 2 - Create a new patron, confirm their lastseen date is null SELECT lastseen FROM borrowers WHERE cardnumber={their cardnumber} 3 - Update preference 'TrackLastPatronActivity' to include 'Patron creation' 4 - Create a second patron, confirm their lastseen is set 5 - Update preference 'TrackLastPatronActivity' to include 'Checking out an item' 6 - Checkout an item to the second patron 7 - Confirm their lastseen is not updated (We only update once per day) I keep getting an error when adding a patron. It seems only happen if I have "Patron creation" checked under the TrackLastPatronActivity. When I fill out the patron creation form and submit I get an error message at the top of the page, "The following fields are wrong. Please fix them." But no fields are listed and no fields appear to be filled out incorrectly. Created attachment 172820 [details] [review] Bug 23486: Add creation to TrackLasPatronActivity triggers Some libraries would like to update the last seen when a patron is created to avoid NULL values and ensure new users are marked as 'active' To test: 1 - Apply patch 2 - Create a new patron, confirm their lastseen date is null SELECT lastseen FROM borrowers WHERE cardnumber={their cardnumber} 3 - Update preference 'TrackLastPatronActivity' to include 'Patron creation' 4 - Create a second patron, confirm their lastseen is set 5 - Update preference 'TrackLastPatronActivity' to include 'Checking out an item' 6 - Checkout an item to the second patron 7 - Confirm their lastseen is not updated (We only update once per day) (In reply to Owen Leonard from comment #33) > I keep getting an error when adding a patron. It seems only happen if I have > "Patron creation" checked under the TrackLastPatronActivity. > > When I fill out the patron creation form and submit I get an error message > at the top of the page, "The following fields are wrong. Please fix them." > But no fields are listed and no fields appear to be filled out incorrectly. updated_on was beign returned as 'current_timestamp', I had to add a refetch of the patron to ensure we got the value Created attachment 172927 [details] [review] Bug 23486: Add creation to TrackLasPatronActivity triggers Some libraries would like to update the last seen when a patron is created to avoid NULL values and ensure new users are marked as 'active' To test: 1 - Apply patch 2 - Create a new patron, confirm their lastseen date is null SELECT lastseen FROM borrowers WHERE cardnumber={their cardnumber} 3 - Update preference 'TrackLastPatronActivity' to include 'Patron creation' 4 - Create a second patron, confirm their lastseen is set 5 - Update preference 'TrackLastPatronActivity' to include 'Checking out an item' 6 - Checkout an item to the second patron 7 - Confirm their lastseen is not updated (We only update once per day) Signed-off-by: David Nind <david@davidnind.com> Created attachment 172928 [details] [review] Bug 23486: (follow-up) Display text for new option Change display text for creation option from "Patron creation" to "Creating a patron" - for consistency with other values. Signed-off-by: David Nind <david@davidnind.com> I updated the display text for the new option to "Creating a patron" (instead of "Patron creation") for consistency with the other options (Checking out an item, Logging in, and so on). Feel free to remove the follow-up patch if you don't agree. I think this is an enhancement/improvement, so changed to an enhancement. But perhaps it should have tracked this from the start, so maybe is a bug? Created attachment 174080 [details] [review] Bug 23486: Add creation to TrackLasPatronActivity triggers Some libraries would like to update the last seen when a patron is created to avoid NULL values and ensure new users are marked as 'active' To test: 1 - Apply patch 2 - Create a new patron, confirm their lastseen date is null SELECT lastseen FROM borrowers WHERE cardnumber={their cardnumber} 3 - Update preference 'TrackLastPatronActivity' to include 'Patron creation' 4 - Create a second patron, confirm their lastseen is set 5 - Update preference 'TrackLastPatronActivity' to include 'Checking out an item' 6 - Checkout an item to the second patron 7 - Confirm their lastseen is not updated (We only update once per day) Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Created attachment 174081 [details] [review] Bug 23486: (follow-up) Display text for new option Change display text for creation option from "Patron creation" to "Creating a patron" - for consistency with other values. Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Pushed for 24.11! Well done everyone, thank you! Thank you everyone! Is a backport possible to 24.05? (In reply to Christofer Zorn from comment #42) > Thank you everyone! Is a backport possible to 24.05? I changed it from a normal bug to an enhancement (see comment #38). Bugs would normally be considered by the Release Maintainer for back porting, generally enhancements aren't. So the question is whether it is an enhancement or not: - Enhancement: adds to or improves a feature, but is not fixing something broken or not working as intended - Bug: something is broken or doesn't work as originally intended I'm not really sure for this one - I can see the case for both! Enhancement, no 24.05.x backport. |