| Summary: | Table borrower_modifications is missing FK and not deleted with the patron | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Katrin Fischer <katrin.fischer> |
| Component: | Database | Assignee: | Jonathan Druart <jonathan.druart> |
| Status: | CLOSED FIXED | QA Contact: | Testopia <testopia> |
| Severity: | major | ||
| Priority: | P5 - low | CC: | 1joynelson, amy, jonathan.druart, nicole |
| Version: | Main | ||
| Hardware: | All | ||
| OS: | All | ||
| Change sponsored?: | --- | Patch complexity: | Small patch |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: |
20.05.00
|
|
| Circulation function: | |||
| Bug Depends on: | |||
| Bug Blocks: | 5334 | ||
| Attachments: |
Bug 13518: Delete patron's modifications along with the patron
Bug 13518: Delete patron's modifications along with the patron Bug 13518: Delete patron's modifications along with the patron |
||
|
Description
Katrin Fischer
2015-01-05 16:28:27 UTC
Upping severity a bit - storing patron information that is/can never be deleted outside of SQL is not nice. The problem is that this table is used for the borrower modifications and the self-registration features. So far borrowernumber is the PK (int(11) NOT NULL DEFAULT '0'), for the self-registration feature we can have borrowernumber that is not defined (0 is used) Ideally we would like to have borrowernumber a DEFAULT NULL, and use NULL for self-reg, but then we will loose the PK (PK cannot be NULL). I do not think we will be able to keep the correct constraints at DB level anyway, we will need to handle consistency at code-level. I see what you by it being used for 2 features. So we have: `verification_token` varchar(255) NOT NULL DEFAULT '', `borrowernumber` int(11) NOT NULL DEFAULT '0', PRIMARY KEY (`verification_token` (191),`borrowernumber`), Because we either have it's either or: modification: borrowernumber != 0 or, no verfication token self registration borrower = 0, verififcation token exists The design, if I understand it correctly, also means that one patron can only have one modification request at a time. And a PK column can not be NULL... as the resulting keys wouldn't be unique any more. The main idea about the FK was to make sure we don't keep storing address and other personal data in there when the patron was long deleted. Would it be simpler to solve that in the method deleting the patron? (where we move the data to deleted_borrowers? It should be in Koha::Patron->delete, yes. Created attachment 103130 [details] [review] Bug 13518: Delete patron's modifications along with the patron The table borrower_modifications has no FK constraint on the borrowernumber and will remain untouched when the patron is deleted. If the borrowernumber doesn't exist in the database, the modification entry is no longer visible in Koha. The problem is that this table is used for the borrower modifications and the self-registration features. So far borrowernumber is the PK (int(11) NOT NULL DEFAULT '0'), for the self-registration feature we can have borrowernumber that is not defined (0 is used) Ideally we would like to have borrowernumber a DEFAULT NULL, and use NULL for self-reg, but then we will loose the PK (PK cannot be NULL). As we cannot keep the correct constraints at DB level anyway, we will need to handle consistency at code-level. Test plan: Create a new patron Do some modification at the OPAC Delete the patron Confirm that the modifications as been removed (directly in DB) Created attachment 103176 [details] [review] Bug 13518: Delete patron's modifications along with the patron The table borrower_modifications has no FK constraint on the borrowernumber and will remain untouched when the patron is deleted. If the borrowernumber doesn't exist in the database, the modification entry is no longer visible in Koha. The problem is that this table is used for the borrower modifications and the self-registration features. So far borrowernumber is the PK (int(11) NOT NULL DEFAULT '0'), for the self-registration feature we can have borrowernumber that is not defined (0 is used) Ideally we would like to have borrowernumber a DEFAULT NULL, and use NULL for self-reg, but then we will loose the PK (PK cannot be NULL). As we cannot keep the correct constraints at DB level anyway, we will need to handle consistency at code-level. Test plan: Create a new patron Do some modification at the OPAC Delete the patron Confirm that the modifications as been removed (directly in DB) Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> Modifications removed, test pass Created attachment 103187 [details] [review] Bug 13518: Delete patron's modifications along with the patron The table borrower_modifications has no FK constraint on the borrowernumber and will remain untouched when the patron is deleted. If the borrowernumber doesn't exist in the database, the modification entry is no longer visible in Koha. The problem is that this table is used for the borrower modifications and the self-registration features. So far borrowernumber is the PK (int(11) NOT NULL DEFAULT '0'), for the self-registration feature we can have borrowernumber that is not defined (0 is used) Ideally we would like to have borrowernumber a DEFAULT NULL, and use NULL for self-reg, but then we will loose the PK (PK cannot be NULL). As we cannot keep the correct constraints at DB level anyway, we will need to handle consistency at code-level. Test plan: Create a new patron Do some modification at the OPAC Delete the patron Confirm that the modifications as been removed (directly in DB) Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> Modifications removed, test pass Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Thx Jonathan! :) Nice work everyone! Pushed to master for 20.05 does not apply to 19.11.x branch. please rebase if needed. |