In the database, vendors can have text in up to 4 address fields. In the staff client, these 4 addresses appear in the same area next to a label of "Physical address". The addresses appear to belong to one field here, and are not separated by a space so the data looks bad. Clicking on Edit allows you to edit the "Physical address" box (containing the combined data from these 4 fields). If you modify the text in this box, and click save, you've modified the location of the data in the database. From that point forward, the vendor only appears to have data in address1, and address2-address4 are set to NULL.
Hi Rocio, I am sorry, but I have tried a few things and I am not sure what this bug is about. When I enter the addresses (postal and physical) on multiple lines they get saved to the database correctly afaikt. The postal address is split into multiple database fields while the physical address is stored in postal. Editing works ok too - it displays as I entered it. Can you try and describe the problem a bit more?
Perhaps the problem is that the system parses the data entered into the textarea and splits it based on line breaks. If you put in more than 4 lines of data the last line will get discarded. We should at the very least add a note to the field about the 4-line limit.
*** Bug 21126 has been marked as a duplicate of this bug. ***
Created attachment 100875 [details] [review] Bug 15272: DBIC changes
Created attachment 100876 [details] [review] Bug 15272: DB changes
Created attachment 100877 [details] [review] Bug 15272: Merge aqbooksellers addressX columns The physical address of a vendor is stored in 4 different DB columns: address1, address2, address3 and address4 The are concatenated and split for storage/display purpose. If you enter an address on more than 4 lines, the other lines are truncated: data loss To avoid such weird behavior, we could simplify the code and get more flexibility (like address as long as you wish) merging those 4 columns into 1, address Test plan: 0. Do not apply the patches 1. Create a vendor and enter more than 4 lines in the physical address, save => Notice that the lines has been stored in the 4 columns, and that you lost the end of the address 2. Apply the patches and execute the updatedatabase script 3. Edit the vendor's address => Notice that the address is displayed correctly 4. Add more lines, save => Notice that the extra lines are kept 5. Generate a ACQCLAIM or ACQORDER notice for this vendor => Confirm that the address is displayed correctly in the generated notice
Created attachment 100878 [details] [review] Bug 15272: Update notice templates
Created attachment 100879 [details] [review] Bug 15272: Update notice templates for all languages
Created attachment 102349 [details] [review] Bug 15272: DBIC changes Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 102350 [details] [review] Bug 15272: DB changes Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 102351 [details] [review] Bug 15272: Merge aqbooksellers addressX columns The physical address of a vendor is stored in 4 different DB columns: address1, address2, address3 and address4 The are concatenated and split for storage/display purpose. If you enter an address on more than 4 lines, the other lines are truncated: data loss To avoid such weird behavior, we could simplify the code and get more flexibility (like address as long as you wish) merging those 4 columns into 1, address Test plan: 0. Do not apply the patches 1. Create a vendor and enter more than 4 lines in the physical address, save => Notice that the lines has been stored in the 4 columns, and that you lost the end of the address 2. Apply the patches and execute the updatedatabase script 3. Edit the vendor's address => Notice that the address is displayed correctly 4. Add more lines, save => Notice that the extra lines are kept 5. Generate a ACQCLAIM or ACQORDER notice for this vendor => Confirm that the address is displayed correctly in the generated notice Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 102352 [details] [review] Bug 15272: Update notice templates Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 102353 [details] [review] Bug 15272: Update notice templates for all languages Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Looks good and works well for me.. Signing off
I am not sure about this approach goes in the right direction. I wonder if it wouldn't be better to split the information into multiple fields in the GUI instead, making it match how we handle addresses for patrons and libraries. Pros: - Allows more than 4 lines in addresses - Doesn't lose data without notifying the user - Makes physical and postal address consistent Cons: - Special handling is needed in HTML notices to keep line breaks - Notices: Harder to parse the address if you want different formatting. Probably possible with TT, but much more complex. Existing notices will have be updated after update or break. - Reports: Existing reports will be broken and it will be much harder to report on specific information. Example: a report on delivery time of vendors in and outside the country. - CSV export: People using serial letters or other ways to create order letters will have to adapt (this would directly affect us as well) - Creates inconsistency in address handling with patrons and libraries Usually we try to avoid creating a need for changes to be made manually after an update, but I don't think we could avoid that here (reports, notices, CSV profiles for basket exports etc.) Some notes for further testing beyond the test plan: - Export reports on vendor data - CSV basket and basket group exports - PDF basket group printing - Vendors API Found some more occurrences of address3 in the PDF templates: Koha/pdfformat/layout2pages.pm: $text->text($bookseller->address3); Koha/pdfformat/layout2pagesde.pm: $text->text($bookseller->address3); Koha/pdfformat/layout3pagesfr.pm: $text->text($bookseller->address3); ... Failing for the last - but maybe we should discuss this a bit more? I hope, I didn't miss something important.
(In reply to Katrin Fischer from comment #15) > Found some more occurrences of address3 in the PDF templates: > Koha/pdfformat/layout2pages.pm: $text->text($bookseller->address3); > Koha/pdfformat/layout2pagesde.pm: $text->text($bookseller->address3); > Koha/pdfformat/layout3pagesfr.pm: $text->text($bookseller->address3); Will fix if we agree on the move. > Failing for the last - but maybe we should discuss this a bit more? I hope, > I didn't miss something important. Switching to In Discussion then...