Some vendors may have more than one contact. For example, a technical contact and a billing contact, or a contact for journals and a contact for monographs. Rather than require that each contact be either made into a separate vendor or recorded somewhere outside of Koha, it would be really useful of Koha had the ability to add multiple additional contacts to vendors i the acquisitions module.
Created attachment 18973 [details] [review] Bug 10402: Use an object for contacts In preparation for adding the ability to handle multiple contacts, this patch moves booksellers' contacts into their own class, C4::Bookseller::Contact. To test: 1) Apply patch. 2) Run database update. 3) Edit a bookseller, making sure to add a contact. 4) View the bookseller's information, making sure the contact information is there. 5) Run the unit test: > prove t/db_dependent/Bookseller.t
Created attachment 18974 [details] [review] Bug 10402: Move contacts to separate table This patch normalizes the data structures used for bookseller contacts. To test: 1) Repeat tests described on previous patch.
Created attachment 18975 [details] [review] Bug 10402: Add ability to enter multiple contacts Some vendors may have more than one contact. For example, a technical contact and a billing contact, or a contact for journals and a contact for monographs. Rather than require that each contact be either made into a separate vendor or recorded somewhere outside of Koha, it would be really useful of Koha had the ability to add multiple additional contacts to vendors in the Acquisitions module. To test: 1) Apply patch. 2) Edit a bookseller, making sure to add a contact. 3) View the bookseller's information, making sure the contact information is there. 4) Run the unit test: > prove t/db_dependent/Bookseller.t 5) Add multiple contacts to a vendor, see that they show up. 6) Delete one contact from a vendor with multiple contacts, see that the result is correct. 7) Sign off. Note: This test plan can supersede that on the previous two patches, as all functionality of the previous two patches is required by this one.
Sandbox setup by laurblain@aol.com with database 2 and bug 10402 on Tue Jun 25 17:48:05 2013 Something went wrong ! Applying: Bug 10402: Use an object for contacts Applying: Bug 10402: Move contacts to separate table Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merging installer/data/mysql/kohastructure.sql Auto-merging installer/data/mysql/updatedatabase.pl CONFLICT (content): Merge conflict in installer/data/mysql/updatedatabase.pl Failed to merge in the changes. Patch failed at 0001 Bug 10402: Move contacts to separate table When you have resolved this problem run "git am --resolved". If you would prefer to skip this patch, instead run "git am --skip". To restore the original branch and stop patching run "git am --abort". Bug 10402 - Add multiple contacts for vendors Bug 10402: Use an object for contacts Apply? [yn] Bug 10402: Move contacts to separate table Apply? [yn] Patch left in /tmp/Bug-10402-Move-contacts-to-separate-table-KsaGBE.patch === translation installation ===
Created attachment 19233 [details] [review] Bug 10402: Use an object for contacts In preparation for adding the ability to handle multiple contacts, this patch moves booksellers' contacts into their own class, C4::Bookseller::Contact. To test: 1) Apply patch. 2) Run database update. 3) Edit a bookseller, making sure to add a contact. 4) View the bookseller's information, making sure the contact information is there. 5) Run the unit test: > prove t/db_dependent/Bookseller.t
Created attachment 19234 [details] [review] Bug 10402: Move contacts to separate table This patch normalizes the data structures used for bookseller contacts. To test: 1) Repeat tests described on previous patch.
Created attachment 19235 [details] [review] Bug 10402: Add ability to enter multiple contacts Some vendors may have more than one contact. For example, a technical contact and a billing contact, or a contact for journals and a contact for monographs. Rather than require that each contact be either made into a separate vendor or recorded somewhere outside of Koha, it would be really useful of Koha had the ability to add multiple additional contacts to vendors in the Acquisitions module. To test: 1) Apply patch. 2) Edit a bookseller, making sure to add a contact. 3) View the bookseller's information, making sure the contact information is there. 4) Run the unit test: > prove t/db_dependent/Bookseller.t 5) Add multiple contacts to a vendor, see that they show up. 6) Delete one contact from a vendor with multiple contacts, see that the result is correct. 7) Sign off. Note: This test plan can supersede that on the previous two patches, as all functionality of the previous two patches is required by this one.
During step 3 of Web Installer, I received this message: Web installer › Step 3 The following error occurred while importing the database structure: ERROR 1064 (42000) at line 2861: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'BOOLEAN not NULL default 0, booksellerid int(11) not NULL, PRIMARY KEY (id' at line 10 Please contact your system administrator
Created attachment 19603 [details] [review] Bug 10402: Move contacts to separate table This patch normalizes the data structures used for bookseller contacts. To test: 1) Repeat tests described on previous patch.
Created attachment 19604 [details] [review] Bug 10402: Add ability to enter multiple contacts Some vendors may have more than one contact. For example, a technical contact and a billing contact, or a contact for journals and a contact for monographs. Rather than require that each contact be either made into a separate vendor or recorded somewhere outside of Koha, it would be really useful of Koha had the ability to add multiple additional contacts to vendors in the Acquisitions module. To test: 1) Apply patch. 2) Edit a bookseller, making sure to add a contact. 3) View the bookseller's information, making sure the contact information is there. 4) Run the unit test: > prove t/db_dependent/Bookseller.t 5) Add multiple contacts to a vendor, see that they show up. 6) Delete one contact from a vendor with multiple contacts, see that the result is correct. 7) Sign off. Note: This test plan can supersede that on the previous two patches, as all functionality of the previous two patches is required by this one.
Auto-merging C4/Bookseller.pm CONFLICT (content): Merge conflict in C4/Bookseller.pm Failed to merge in the changes.
Created attachment 19808 [details] [review] Bug 10402: Use an object for contacts In preparation for adding the ability to handle multiple contacts, this patch moves booksellers' contacts into their own class, C4::Bookseller::Contact. To test: 1) Apply patch. 2) Run database update. 3) Edit a bookseller, making sure to add a contact. 4) View the bookseller's information, making sure the contact information is there. 5) Run the unit test: > prove t/db_dependent/Bookseller.t
Created attachment 19809 [details] [review] Bug 10402: Move contacts to separate table This patch normalizes the data structures used for bookseller contacts. To test: 1) Repeat tests described on previous patch.
Created attachment 19810 [details] [review] Bug 10402: Add ability to enter multiple contacts Some vendors may have more than one contact. For example, a technical contact and a billing contact, or a contact for journals and a contact for monographs. Rather than require that each contact be either made into a separate vendor or recorded somewhere outside of Koha, it would be really useful of Koha had the ability to add multiple additional contacts to vendors in the Acquisitions module. To test: 1) Apply patch. 2) Edit a bookseller, making sure to add a contact. 3) View the bookseller's information, making sure the contact information is there. 4) Run the unit test: > prove t/db_dependent/Bookseller.t 5) Add multiple contacts to a vendor, see that they show up. 6) Delete one contact from a vendor with multiple contacts, see that the result is correct. 7) Sign off. Note: This test plan can supersede that on the previous two patches, as all functionality of the previous two patches is required by this one.
Created attachment 20019 [details] [review] Bug 10402: Use an object for contacts In preparation for adding the ability to handle multiple contacts, this patch moves booksellers' contacts into their own class, C4::Bookseller::Contact. To test: 1) Apply patch. 2) Run database update. 3) Edit a bookseller, making sure to add a contact. 4) View the bookseller's information, making sure the contact information is there. 5) Run the unit test: > prove t/db_dependent/Bookseller.t
Created attachment 20020 [details] [review] Bug 10402: Move contacts to separate table This patch normalizes the data structures used for bookseller contacts. To test: 1) Repeat tests described on previous patch.
Created attachment 20021 [details] [review] Bug 10402: Add ability to enter multiple contacts Some vendors may have more than one contact. For example, a technical contact and a billing contact, or a contact for journals and a contact for monographs. Rather than require that each contact be either made into a separate vendor or recorded somewhere outside of Koha, it would be really useful of Koha had the ability to add multiple additional contacts to vendors in the Acquisitions module. To test: 1) Apply patch. 2) Edit a bookseller, making sure to add a contact. 3) View the bookseller's information, making sure the contact information is there. 4) Run the unit test: > prove t/db_dependent/Bookseller.t 5) Add multiple contacts to a vendor, see that they show up. 6) Delete one contact from a vendor with multiple contacts, see that the result is correct. 7) Sign off. Note: This test plan can supersede that on the previous two patches, as all functionality of the previous two patches is required by this one.
Created attachment 20045 [details] [review] [SIGNED-OFF] Bug 10402: Use an object for contacts In preparation for adding the ability to handle multiple contacts, this patch moves booksellers' contacts into their own class, C4::Bookseller::Contact. To test: 1) Apply patch. 2) Run database update. 3) Edit a bookseller, making sure to add a contact. 4) View the bookseller's information, making sure the contact information is there. 5) Run the unit test: > prove t/db_dependent/Bookseller.t Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Created attachment 20046 [details] [review] [SIGNED-OFF] Bug 10402: Move contacts to separate table This patch normalizes the data structures used for bookseller contacts. To test: 1) Repeat tests described on previous patch. Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Created attachment 20047 [details] [review] [SIGNED-OFF] Bug 10402: Add ability to enter multiple contacts Some vendors may have more than one contact. For example, a technical contact and a billing contact, or a contact for journals and a contact for monographs. Rather than require that each contact be either made into a separate vendor or recorded somewhere outside of Koha, it would be really useful of Koha had the ability to add multiple additional contacts to vendors in the Acquisitions module. To test: 1) Apply patch. 2) Edit a bookseller, making sure to add a contact. 3) View the bookseller's information, making sure the contact information is there. 4) Run the unit test: > prove t/db_dependent/Bookseller.t 5) Add multiple contacts to a vendor, see that they show up. 6) Delete one contact from a vendor with multiple contacts, see that the result is correct. 7) Sign off. Note: This test plan can supersede that on the previous two patches, as all functionality of the previous two patches is required by this one. Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Created attachment 20048 [details] [review] Bug 10402 [Template follow-up] Add multiple contacts for vendors This template-only follow-up tweaks the button labels and restructures the vendor view layout a little bit to make it more amenable to multiple contacts: - Add spaces after button icons - Change "Add contact" to "Add another contact" in hopes of making it less ambiguous whether clicking it will submit the whole form. - Eliminate duplicate headers on the vendor view page by making the contact name the subheading for each individual contact. To test, view details for vendors with one or more contacts, and try editing to add additional contacts. Everything should look good and work correctly.
Created attachment 20559 [details] [review] Bug 10402: Use an object for contacts In preparation for adding the ability to handle multiple contacts, this patch moves booksellers' contacts into their own class, C4::Bookseller::Contact. To test: 1) Apply patch. 2) Run database update. 3) Edit a bookseller, making sure to add a contact. 4) View the bookseller's information, making sure the contact information is there. 5) Run the unit test: > prove t/db_dependent/Bookseller.t Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Created attachment 20560 [details] [review] Bug 10402: Move contacts to separate table This patch normalizes the data structures used for bookseller contacts. To test: 1) Repeat tests described on previous patch. Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Created attachment 20561 [details] [review] Bug 10402: Add ability to enter multiple contacts Some vendors may have more than one contact. For example, a technical contact and a billing contact, or a contact for journals and a contact for monographs. Rather than require that each contact be either made into a separate vendor or recorded somewhere outside of Koha, it would be really useful of Koha had the ability to add multiple additional contacts to vendors in the Acquisitions module. To test: 1) Apply patch. 2) Edit a bookseller, making sure to add a contact. 3) View the bookseller's information, making sure the contact information is there. 4) Run the unit test: > prove t/db_dependent/Bookseller.t 5) Add multiple contacts to a vendor, see that they show up. 6) Delete one contact from a vendor with multiple contacts, see that the result is correct. 7) Sign off. Note: This test plan can supersede that on the previous two patches, as all functionality of the previous two patches is required by this one. Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Created attachment 20562 [details] [review] Bug 10402 [Template follow-up] Add multiple contacts for vendors This template-only follow-up tweaks the button labels and restructures the vendor view layout a little bit to make it more amenable to multiple contacts: - Add spaces after button icons - Change "Add contact" to "Add another contact" in hopes of making it less ambiguous whether clicking it will submit the whole form. - Eliminate duplicate headers on the vendor view page by making the contact name the subheading for each individual contact. To test, view details for vendors with one or more contacts, and try editing to add additional contacts. Everything should look good and work correctly. Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Hi Jared, can you please rebase? Thx! # both modified: C4/Bookseller.pm # both added: t/db_dependent/Bookseller.t
Created attachment 21019 [details] [review] Bug 10402: Use an object for contacts In preparation for adding the ability to handle multiple contacts, this patch moves booksellers' contacts into their own class, C4::Bookseller::Contact. To test: 1) Apply patch. 2) Run database update. 3) Edit a bookseller, making sure to add a contact. 4) View the bookseller's information, making sure the contact information is there. 5) Run the unit test: > prove t/db_dependent/Bookseller.t Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Created attachment 21020 [details] [review] Bug 10402: Move contacts to separate table This patch normalizes the data structures used for bookseller contacts. To test: 1) Repeat tests described on previous patch. Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Created attachment 21021 [details] [review] Bug 10402: Add ability to enter multiple contacts Some vendors may have more than one contact. For example, a technical contact and a billing contact, or a contact for journals and a contact for monographs. Rather than require that each contact be either made into a separate vendor or recorded somewhere outside of Koha, it would be really useful of Koha had the ability to add multiple additional contacts to vendors in the Acquisitions module. To test: 1) Apply patch. 2) Edit a bookseller, making sure to add a contact. 3) View the bookseller's information, making sure the contact information is there. 4) Run the unit test: > prove t/db_dependent/Bookseller.t 5) Add multiple contacts to a vendor, see that they show up. 6) Delete one contact from a vendor with multiple contacts, see that the result is correct. 7) Sign off. Note: This test plan can supersede that on the previous two patches, as all functionality of the previous two patches is required by this one. Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Created attachment 21022 [details] [review] Bug 10402 [Template follow-up] Add multiple contacts for vendors This template-only follow-up tweaks the button labels and restructures the vendor view layout a little bit to make it more amenable to multiple contacts: - Add spaces after button icons - Change "Add contact" to "Add another contact" in hopes of making it less ambiguous whether clicking it will submit the whole form. - Eliminate duplicate headers on the vendor view page by making the contact name the subheading for each individual contact. To test, view details for vendors with one or more contacts, and try editing to add additional contacts. Everything should look good and work correctly. Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Created attachment 21023 [details] [review] Bug 10402 follow-up: rebase onto latest master Because of the complexity of the rebase, I have chosen to correct a couple merge errors in a separate patch rather than squashing the corrections into the last patch in the patchset. This rebase patch does one thing that may not be completely obvious: in order to keep the existing tests matching their stated aims, it centralizes contact-related unit testing at the end of the Bookseller.t unit test, and removes contacts from earlier tests.
FAIL acqui/supplier.pl OK pod OK forbidden patterns FAIL valid Type of arg 1 to keys must be hash (not private variable) acqui/supplier.pl had compilation errors. OK critic
Created attachment 21056 [details] [review] Bug 10402 follow-up: fix perlcritic exception Perlcritic doesn't like the syntax keys $variable, and requires that you explicitly dereference a hashref to a hash before using keys.
Hi Jared, I think this is a great improvement and it works nicely in the UI, but there are 2 concerns: - aqcontacts.rank is not used as far as I can see - it seems to break use of the contact fields in serials and acquisition claim letters. Could you please take a look?
Created attachment 21547 [details] [review] Bug 10402 follow-up: choose contacts for serials and acq claims This patch makes it possible to choose a particular contact for acquisitions and serials claims. To test: 1) Select a contact to use for claiming late orders and a contact to use for claiming late issues. 2) Send a claim for a late order and a claim for a late issue. 3) Note that the claims went out to the proper people. 4) Sign off. Note: the claim messages are recorded in the logs in the *Acquisitions* module, not the Letters module as you might expect
Created attachment 21549 [details] [review] Bug 10402 follow-up: choose contacts for serials and acq claims This patch makes it possible to choose a particular contact for acquisitions and serials claims. To test: 1) Select a contact to use for claiming late orders and a contact to use for claiming late issues. 2) Send a claim for a late order and a claim for a late issue. 3) Note that the claims went out to the proper people. 4) Run the unit test with: > prove t/db_dependent/Letters.t 5) Sign off. Note: the claim messages are recorded in the logs in the *Acquisitions* module, not the Letters module as you might expect
Patch applied cleanly, go forth and signoff
There is a problem in updatedatabase.pl this creates the table, note selected columns (->) $dbh->do("CREATE TABLE aqcontacts ( id int(11) NOT NULL auto_increment, name varchar(100) default NULL, position varchar(100) default NULL, phone varchar(100) default NULL, altphone varchar(100) default NULL, fax varchar(100) default NULL, email varchar(100) default NULL, notes mediumtext, -> claimacquisition BOOLEAN NOT NULL DEFAULT 0, -> claimissues BOOLEAN NOT NULL DEFAULT 0, booksellerid int(11) not NULL, PRIMARY KEY (id), CONSTRAINT booksellerid_fk2 FOREIGN KEY (booksellerid) REFERENCES aqbooksellers (id) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1;"); this try to insert into non-existent columns (->) $dbh->do("INSERT INTO aqcontacts (name, position, phone, altphone, fax, email, notes, booksellerid, -> acq_claim, -> serial_claim) perl installer/data/mysql/updatedatabase.pl DBD::mysql::db do failed: Unknown column 'acq_claim' in 'field list' at installer/data/mysql/updatedatabase.pl line 7176.
Created attachment 21804 [details] [review] Bug 10402 follow-up: choose contacts for serials and acq claims This patch makes it possible to choose a particular contact for acquisitions and serials claims. To test: 1) Select a contact to use for claiming late orders and a contact to use for claiming late issues. 2) Send a claim for a late order and a claim for a late issue. 3) Note that the claims went out to the proper people. 4) Run the unit test with: > prove t/db_dependent/Letters.t 5) Sign off. Note: the claim messages are recorded in the logs in the *Acquisitions* module, not the Letters module as you might expect
Applying: Bug 10402: Use an object for contacts Using index info to reconstruct a base tree... M C4/Bookseller.pm M acqui/uncertainprice.pl M koha-tmpl/intranet-tmpl/prog/en/css/staff-global.css M koha-tmpl/intranet-tmpl/prog/en/modules/acqui/supplier.tt M t/db_dependent/Bookseller.t Falling back to patching base and 3-way merge... Auto-merging t/db_dependent/Bookseller.t CONFLICT (content): Merge conflict in t/db_dependent/Bookseller.t Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/acqui/supplier.tt Auto-merging koha-tmpl/intranet-tmpl/prog/en/css/staff-global.css Auto-merging acqui/uncertainprice.pl CONFLICT (content): Merge conflict in acqui/uncertainprice.pl Auto-merging C4/Bookseller.pm Patch failed at 0001 Bug 10402: Use an object for contacts The copy of the patch that failed is found in: /home/christopher/git/koha/.git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
Created attachment 23370 [details] [review] Bug 10402: Use an object for contacts In preparation for adding the ability to handle multiple contacts, this patch moves booksellers' contacts into their own class, C4::Bookseller::Contact. To test: 1) Apply patch. 2) Run database update. 3) Edit a bookseller, making sure to add a contact. 4) View the bookseller's information, making sure the contact information is there. 5) Run the unit test: > prove t/db_dependent/Bookseller.t Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Created attachment 23371 [details] [review] Bug 10402: Move contacts to separate table This patch normalizes the data structures used for bookseller contacts. To test: 1) Repeat tests described on previous patch. Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Created attachment 23372 [details] [review] Bug 10402: Add ability to enter multiple contacts Some vendors may have more than one contact. For example, a technical contact and a billing contact, or a contact for journals and a contact for monographs. Rather than require that each contact be either made into a separate vendor or recorded somewhere outside of Koha, it would be really useful of Koha had the ability to add multiple additional contacts to vendors in the Acquisitions module. To test: 1) Apply patch. 2) Edit a bookseller, making sure to add a contact. 3) View the bookseller's information, making sure the contact information is there. 4) Run the unit test: > prove t/db_dependent/Bookseller.t 5) Add multiple contacts to a vendor, see that they show up. 6) Delete one contact from a vendor with multiple contacts, see that the result is correct. 7) Sign off. Note: This test plan can supersede that on the previous two patches, as all functionality of the previous two patches is required by this one. Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Created attachment 23373 [details] [review] Bug 10402 [Template follow-up] Add multiple contacts for vendors This template-only follow-up tweaks the button labels and restructures the vendor view layout a little bit to make it more amenable to multiple contacts: - Add spaces after button icons - Change "Add contact" to "Add another contact" in hopes of making it less ambiguous whether clicking it will submit the whole form. - Eliminate duplicate headers on the vendor view page by making the contact name the subheading for each individual contact. To test, view details for vendors with one or more contacts, and try editing to add additional contacts. Everything should look good and work correctly. Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Created attachment 23374 [details] [review] Bug 10402 follow-up: rebase onto latest master Because of the complexity of the rebase, I have chosen to correct a couple merge errors in a separate patch rather than squashing the corrections into the last patch in the patchset. This rebase patch does one thing that may not be completely obvious: in order to keep the existing tests matching their stated aims, it centralizes contact-related unit testing at the end of the Bookseller.t unit test, and removes contacts from earlier tests.
Created attachment 23375 [details] [review] Bug 10402 follow-up: fix perlcritic exception Perlcritic doesn't like the syntax keys $variable, and requires that you explicitly dereference a hashref to a hash before using keys.
Created attachment 23376 [details] [review] Bug 10402 follow-up: choose contacts for serials and acq claims This patch makes it possible to choose a particular contact for acquisitions and serials claims. To test: 1) Select a contact to use for claiming late orders and a contact to use for claiming late issues. 2) Send a claim for a late order and a claim for a late issue. 3) Note that the claims went out to the proper people. 4) Run the unit test with: > prove t/db_dependent/Letters.t 5) Sign off. Note: the claim messages are recorded in the logs in the *Acquisitions* module, not the Letters module as you might expect
Created attachment 23377 [details] [review] Bug 10402: correct number of tests When merging t/db_dependent/Bookseller.t, the number of tests listed was not changed, causing the test to fail with too many tests.
Created attachment 24561 [details] [review] Bug 10402: Use an object for contacts In preparation for adding the ability to handle multiple contacts, this patch moves booksellers' contacts into their own class, C4::Bookseller::Contact. To test: 1) Apply patch. 2) Run database update. 3) Edit a bookseller, making sure to add a contact. 4) View the bookseller's information, making sure the contact information is there. 5) Run the unit test: > prove t/db_dependent/Bookseller.t Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Created attachment 24562 [details] [review] Bug 10402: Move contacts to separate table This patch normalizes the data structures used for bookseller contacts. To test: 1) Repeat tests described on previous patch. Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Created attachment 24563 [details] [review] Bug 10402: Add ability to enter multiple contacts Some vendors may have more than one contact. For example, a technical contact and a billing contact, or a contact for journals and a contact for monographs. Rather than require that each contact be either made into a separate vendor or recorded somewhere outside of Koha, it would be really useful of Koha had the ability to add multiple additional contacts to vendors in the Acquisitions module. To test: 1) Apply patch. 2) Edit a bookseller, making sure to add a contact. 3) View the bookseller's information, making sure the contact information is there. 4) Run the unit test: > prove t/db_dependent/Bookseller.t 5) Add multiple contacts to a vendor, see that they show up. 6) Delete one contact from a vendor with multiple contacts, see that the result is correct. 7) Sign off. Note: This test plan can supersede that on the previous two patches, as all functionality of the previous two patches is required by this one. Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Created attachment 24564 [details] [review] Bug 10402 [Template follow-up] Add multiple contacts for vendors This template-only follow-up tweaks the button labels and restructures the vendor view layout a little bit to make it more amenable to multiple contacts: - Add spaces after button icons - Change "Add contact" to "Add another contact" in hopes of making it less ambiguous whether clicking it will submit the whole form. - Eliminate duplicate headers on the vendor view page by making the contact name the subheading for each individual contact. To test, view details for vendors with one or more contacts, and try editing to add additional contacts. Everything should look good and work correctly. Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Created attachment 24565 [details] [review] Bug 10402 follow-up: rebase onto latest master Because of the complexity of the rebase, I have chosen to correct a couple merge errors in a separate patch rather than squashing the corrections into the last patch in the patchset. This rebase patch does one thing that may not be completely obvious: in order to keep the existing tests matching their stated aims, it centralizes contact-related unit testing at the end of the Bookseller.t unit test, and removes contacts from earlier tests.
Created attachment 24566 [details] [review] Bug 10402 follow-up: fix perlcritic exception Perlcritic doesn't like the syntax keys $variable, and requires that you explicitly dereference a hashref to a hash before using keys.
Created attachment 24567 [details] [review] Bug 10402 follow-up: choose contacts for serials and acq claims This patch makes it possible to choose a particular contact for acquisitions and serials claims. To test: 1) Select a contact to use for claiming late orders and a contact to use for claiming late issues. 2) Send a claim for a late order and a claim for a late issue. 3) Note that the claims went out to the proper people. 4) Run the unit test with: > prove t/db_dependent/Letters.t 5) Sign off. Note: the claim messages are recorded in the logs in the *Acquisitions* module, not the Letters module as you might expect
Created attachment 24568 [details] [review] Bug 10402: correct number of tests When merging t/db_dependent/Bookseller.t, the number of tests listed was not changed, causing the test to fail with too many tests. All patches rebased on master 2014/01/19
It seems I cannot deactivate the 2 values claimacquisition and claimissues (on editing a supplier). The 2 checkboxes are always checked. I don't see (in the code) where you check the aqcontacts.claimacquisition flag before sending a claim for late orders. It seems only the first contact is notified, is it wanted? Marked as Failed QA.
Created attachment 29223 [details] [review] Bug 10402: Use an object for contacts In preparation for adding the ability to handle multiple contacts, this patch moves booksellers' contacts into their own class, C4::Bookseller::Contact. To test: 1) Apply patch. 2) Run database update. 3) Edit a bookseller, making sure to add a contact. 4) View the bookseller's information, making sure the contact information is there. 5) Run the unit test: > prove t/db_dependent/Bookseller.t Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Created attachment 29224 [details] [review] Bug 10402: Move contacts to separate table This patch normalizes the data structures used for bookseller contacts. To test: 1) Repeat tests described on previous patch. Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Created attachment 29225 [details] [review] Bug 10402: Add ability to enter multiple contacts Some vendors may have more than one contact. For example, a technical contact and a billing contact, or a contact for journals and a contact for monographs. Rather than require that each contact be either made into a separate vendor or recorded somewhere outside of Koha, it would be really useful of Koha had the ability to add multiple additional contacts to vendors in the Acquisitions module. To test: 1) Apply patch. 2) Edit a bookseller, making sure to add a contact. 3) View the bookseller's information, making sure the contact information is there. 4) Run the unit test: > prove t/db_dependent/Bookseller.t 5) Add multiple contacts to a vendor, see that they show up. 6) Delete one contact from a vendor with multiple contacts, see that the result is correct. 7) Sign off. Note: This test plan can supersede that on the previous two patches, as all functionality of the previous two patches is required by this one. Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Created attachment 29226 [details] [review] Bug 10402 [Template follow-up] Add multiple contacts for vendors This template-only follow-up tweaks the button labels and restructures the vendor view layout a little bit to make it more amenable to multiple contacts: - Add spaces after button icons - Change "Add contact" to "Add another contact" in hopes of making it less ambiguous whether clicking it will submit the whole form. - Eliminate duplicate headers on the vendor view page by making the contact name the subheading for each individual contact. To test, view details for vendors with one or more contacts, and try editing to add additional contacts. Everything should look good and work correctly. Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Created attachment 29227 [details] [review] Bug 10402 follow-up: choose contacts for claims This patch makes it possible to choose a particular contact for acquisitions and serials claims. To test: 1) Select a contact to use for claiming late orders and a contact to use for claiming late issues. 2) Send a claim for a late order and a claim for a late issue. 3) Note that the claims went out to the proper people. 4) Run the unit test with: > prove t/db_dependent/Letters.t 5) Sign off. Note: the claim messages are recorded in the logs in the *Acquisitions* module, not the Letters module as you might expect This patch also fixes several perlcritic violations and centralizes contact-related unit testing in Bookseller.t.
I've applied against master 3.1.7.00.008. I've tried to update database, and an error occurred: Update report : Upgrade to 3.17.00.009 done (Bug 10402: Move bookseller contacts to separate table) Update errors : [Fri Jun 27 14:44:13 2014] updatedatabase.pl: DBD::mysql::db do failed: Unknown column 'acquisitionprimary' in 'field list' at /var/root-koha/bug-7162/installer/data/mysql/updatedatabase.pl line 8583. So I've passed the patch to "Failed QA" status. ---------------------------------------------------------------------- After having passed acquisitionprimary to acqprimary, another error occured: Update errors : [Fri Jun 27 15:07:19 2014] updatedatabase.pl: DBD::mysql::db do failed: Unknown column 'issuesprimary' in 'field list' at /var/root-koha/bug-7162/installer/data/mysql/updatedatabase.pl line 8583. After having passed issuesprimary to acqprimary, updating the DB was OK. Going on, on editing a vendor an empty contact was always listed before the filled contacts. So "Save" could add a further contact, whilest "Add another contact" didn't seem to be needed. I have not been able to delete one contact from a vendor with multiple contacts selecting "x Delete contact".
Today I've tried against master 3.17.00.009 After I've replaced [in th 5-th patch to apply, line 274]: "acquisitionprimary" with "acqprimary", "issuesprimary" with "serialsprimary", updating the DB was OK. I've kept the "Failed QA" status.
(In reply to Paola Rossi from comment #63) > Going on, on editing a vendor an empty contact was always listed before the > filled contacts. So "Save" could add a further contact, whilest "Add another > contact" didn't seem to be needed. > I have not been able to delete one contact from a vendor with multiple > contacts selecting "x Delete contact". I have a patch which fixes the update and the contact deleting. The empty contact is intentional- there should always be one contact visible when you open up the form, because otherwise you might forget to enter any contact information you might have.
Created attachment 29511 [details] [review] Bug 10402 follow-up: choose contacts for claims This patch makes it possible to choose a particular contact for acquisitions and serials claims. To test: 1) Select a contact to use for claiming late orders and a contact to use for claiming late issues. 2) Send a claim for a late order and a claim for a late issue. 3) Note that the claims went out to the proper people. 4) Run the unit test with: > prove t/db_dependent/Letters.t 5) Sign off. Note: the claim messages are recorded in the logs in the *Acquisitions* module, not the Letters module as you might expect This patch also fixes several perlcritic violations and centralizes contact-related unit testing in Bookseller.t.
I've tried to apply against master 3.17.00.009 Applying: Bug 10402 follow-up: choose contacts for claims Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merging t/db_dependent/Letters.t CONFLICT (content): Merge conflict in t/db_dependent/Letters.t Auto-merging t/db_dependent/Bookseller.t Auto-merging installer/data/mysql/updatedatabase.pl CONFLICT (content): Merge conflict in installer/data/mysql/updatedatabase.pl Failed to merge in the changes. So I've passed the patch to "Failed QA" status.
[I beg your pardon.] I've tried to apply against master 3.17.00.009 Applying: Bug 10402 follow-up: choose contacts for claims Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merging t/db_dependent/Letters.t CONFLICT (content): Merge conflict in t/db_dependent/Letters.t Auto-merging t/db_dependent/Bookseller.t Auto-merging installer/data/mysql/updatedatabase.pl CONFLICT (content): Merge conflict in installer/data/mysql/updatedatabase.pl Failed to merge in the changes. I've passed the patch to "Patch doesn't apply" status.
Created attachment 29600 [details] [review] Bug 10402: Use an object for contacts In preparation for adding the ability to handle multiple contacts, this patch moves booksellers' contacts into their own class, C4::Bookseller::Contact. To test: 1) Apply patch. 2) Run database update. 3) Edit a bookseller, making sure to add a contact. 4) View the bookseller's information, making sure the contact information is there. 5) Run the unit test: > prove t/db_dependent/Bookseller.t Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Created attachment 29601 [details] [review] Bug 10402: Move contacts to separate table This patch normalizes the data structures used for bookseller contacts. To test: 1) Repeat tests described on previous patch. Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Created attachment 29602 [details] [review] Bug 10402: Add ability to enter multiple contacts Some vendors may have more than one contact. For example, a technical contact and a billing contact, or a contact for journals and a contact for monographs. Rather than require that each contact be either made into a separate vendor or recorded somewhere outside of Koha, it would be really useful of Koha had the ability to add multiple additional contacts to vendors in the Acquisitions module. To test: 1) Apply patch. 2) Edit a bookseller, making sure to add a contact. 3) View the bookseller's information, making sure the contact information is there. 4) Run the unit test: > prove t/db_dependent/Bookseller.t 5) Add multiple contacts to a vendor, see that they show up. 6) Delete one contact from a vendor with multiple contacts, see that the result is correct. 7) Sign off. Note: This test plan can supersede that on the previous two patches, as all functionality of the previous two patches is required by this one. Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Created attachment 29603 [details] [review] Bug 10402 [Template follow-up] Add multiple contacts for vendors This template-only follow-up tweaks the button labels and restructures the vendor view layout a little bit to make it more amenable to multiple contacts: - Add spaces after button icons - Change "Add contact" to "Add another contact" in hopes of making it less ambiguous whether clicking it will submit the whole form. - Eliminate duplicate headers on the vendor view page by making the contact name the subheading for each individual contact. To test, view details for vendors with one or more contacts, and try editing to add additional contacts. Everything should look good and work correctly. Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Created attachment 29604 [details] [review] Bug 10402 follow-up: choose contacts for claims This patch makes it possible to choose a particular contact for acquisitions and serials claims. To test: 1) Select a contact to use for claiming late orders and a contact to use for claiming late issues. 2) Send a claim for a late order and a claim for a late issue. 3) Note that the claims went out to the proper people. 4) Run the unit test with: > prove t/db_dependent/Letters.t 5) Sign off. Note: the claim messages are recorded in the logs in the *Acquisitions* module, not the Letters module as you might expect This patch also fixes several perlcritic violations and centralizes contact-related unit testing in Bookseller.t.
I've applied the patches against master 3.17.00.009 I've added a vendor. I've added a contact [filling the "Notes" field]. I've saved the vendor. 1) I've edited the vendor. The "Notes" field of the contact is shown empty. 2) I've filled the "Email" field of the contact with such a string : XXXXX I've selected "Save". The system has given no error, instead of sending "Please enter a valid email address" error. 3) I've tried to send late orders. The system has shown: "Email has been sent" but I (I'm the vendor...) have received no mail. On apache' log: [Fri Jul 11 17:09:29] lateorders.pl at line 107: Bad or missing From address: '' It seems SendAlerts line 366 has no mail in $userenv->{emailaddress}. [The "Primary email", "Secondary email" and "Alternate address' email" fields of the patron/login-user are set well.] 4) I've tried to send serials claims. I've "sent a notification". The system has given me no feedback, the subscription has become in "Claimed" status, but I've received no mail. On apache' log: [Fri Jul 11 17:29:43] claims.pl at line 78: Bad or missing From address: '' ---------------------------------------------------------------------------- So I've passed the patch to "Failed QA" status. --------------------------------------------------------------------------- NB. Soon after having saved the vendor "XX", I see: Home > Acquisition > Search for vendor Y, where Y is the id of the aqbookseller "XX". IMO Y is instead of the vendor's name, which can be searched.
(In reply to Paola Rossi from comment #74) > 1) I've edited the vendor. The "Notes" field of the contact is shown empty. Good catch! Issues 2-4 and the breadcrumbs you mention are outside the scope of this development. The following are true of Koha going back to 3.8 at least (so far as I can tell): 2) you can save an invalid e-mail address 3-4) notices will fail if you don't have an e-mail address set up for your account 5) you will see the vendor ID number rather than the vendor name in breadcrumbs after saving a vendor.
Created attachment 29761 [details] [review] Bug 10402 follow-up: choose contacts for claims This patch makes it possible to choose a particular contact for acquisitions and serials claims. To test: 1) Select a contact to use for claiming late orders and a contact to use for claiming late issues. 2) Send a claim for a late order and a claim for a late issue. 3) Note that the claims went out to the proper people. 4) Run the unit test with: > prove t/db_dependent/Letters.t 5) Sign off. Note: the claim messages are recorded in the logs in the *Acquisitions* module, not the Letters module as you might expect This patch also fixes several perlcritic violations and centralizes contact-related unit testing in Bookseller.t.
Thanks, Jared. I've tried to apply the patches against master 3.17.00.010. Applying: Bug 10402: Use an object for contacts Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merging koha-tmpl/intranet-tmpl/prog/en/css/staff-global.css Auto-merging acqui/uncertainprice.pl Auto-merging acqui/supplier.pl So I pass the patch to "Patch doesn't apply" status.
Created attachment 30209 [details] [review] Bug 10402: Use an object for contacts In preparation for adding the ability to handle multiple contacts, this patch moves booksellers' contacts into their own class, C4::Bookseller::Contact. To test: 1) Apply patch. 2) Run database update. 3) Edit a bookseller, making sure to add a contact. 4) View the bookseller's information, making sure the contact information is there. 5) Run the unit test: > prove t/db_dependent/Bookseller.t Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Created attachment 30210 [details] [review] Bug 10402: Move contacts to separate table This patch normalizes the data structures used for bookseller contacts. To test: 1) Repeat tests described on previous patch. Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Created attachment 30211 [details] [review] Bug 10402: Add ability to enter multiple contacts Some vendors may have more than one contact. For example, a technical contact and a billing contact, or a contact for journals and a contact for monographs. Rather than require that each contact be either made into a separate vendor or recorded somewhere outside of Koha, it would be really useful of Koha had the ability to add multiple additional contacts to vendors in the Acquisitions module. To test: 1) Apply patch. 2) Edit a bookseller, making sure to add a contact. 3) View the bookseller's information, making sure the contact information is there. 4) Run the unit test: > prove t/db_dependent/Bookseller.t 5) Add multiple contacts to a vendor, see that they show up. 6) Delete one contact from a vendor with multiple contacts, see that the result is correct. 7) Sign off. Note: This test plan can supersede that on the previous two patches, as all functionality of the previous two patches is required by this one. Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Created attachment 30212 [details] [review] Bug 10402 [Template follow-up] Add multiple contacts for vendors This template-only follow-up tweaks the button labels and restructures the vendor view layout a little bit to make it more amenable to multiple contacts: - Add spaces after button icons - Change "Add contact" to "Add another contact" in hopes of making it less ambiguous whether clicking it will submit the whole form. - Eliminate duplicate headers on the vendor view page by making the contact name the subheading for each individual contact. To test, view details for vendors with one or more contacts, and try editing to add additional contacts. Everything should look good and work correctly. Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Created attachment 30213 [details] [review] Bug 10402 follow-up: choose contacts for claims This patch makes it possible to choose a particular contact for acquisitions and serials claims. To test: 1) Select a contact to use for claiming late orders and a contact to use for claiming late issues. 2) Send a claim for a late order and a claim for a late issue. 3) Note that the claims went out to the proper people. 4) Run the unit test with: > prove t/db_dependent/Letters.t 5) Sign off. Note: the claim messages are recorded in the logs in the *Acquisitions* module, not the Letters module as you might expect This patch also fixes several perlcritic violations and centralizes contact-related unit testing in Bookseller.t.
Today I've tried to apply against 3.17.00.011 Applying: Bug 10402: Use an object for contacts Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merging acqui/supplier.pl So I pass the patch to "Patch doesn't apply" status
(In reply to Paola Rossi from comment #83) > Today I've tried to apply against 3.17.00.011 > > Applying: Bug 10402: Use an object for contacts > Using index info to reconstruct a base tree... > Falling back to patching base and 3-way merge... > Auto-merging acqui/supplier.pl > > So I pass the patch to "Patch doesn't apply" status This message doesn't mean that the patch doesn't apply. It's just telling you that there were other changes made to acqui/supplier.pl.
Thanks, Jared. I've applied against 3.17.00.011. Everything's ok. So I pass the patches to "Signed Off" status.
Created attachment 30460 [details] [review] Bug 10402: Use an object for contacts
Created attachment 30461 [details] [review] Bug 10402: Move contacts to separate table
Created attachment 30462 [details] [review] Bug 10402: Add ability to enter multiple contacts
Created attachment 30463 [details] [review] Bug 10402 [Template follow-up] Add multiple contacts for vendors
Created attachment 30464 [details] [review] Bug 10402 follow-up: choose contacts for claims
Created attachment 31091 [details] [review] Bug 10402: Use an object for contacts In preparation for adding the ability to handle multiple contacts, this patch moves booksellers' contacts into their own class, C4::Bookseller::Contact. To test: 1) Apply patch. 2) Run database update. 3) Edit a bookseller, making sure to add a contact. 4) View the bookseller's information, making sure the contact information is there. 5) Run the unit test: > prove t/db_dependent/Bookseller.t Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com> Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Created attachment 31092 [details] [review] Bug 10402: Move contacts to separate table This patch normalizes the data structures used for bookseller contacts. To test: 1) Repeat tests described on previous patch. Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com> Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Created attachment 31093 [details] [review] Bug 10402: Add ability to enter multiple contacts Some vendors may have more than one contact. For example, a technical contact and a billing contact, or a contact for journals and a contact for monographs. Rather than require that each contact be either made into a separate vendor or recorded somewhere outside of Koha, it would be really useful of Koha had the ability to add multiple additional contacts to vendors in the Acquisitions module. To test: 1) Apply patch. 2) Edit a bookseller, making sure to add a contact. 3) View the bookseller's information, making sure the contact information is there. 4) Run the unit test: > prove t/db_dependent/Bookseller.t 5) Add multiple contacts to a vendor, see that they show up. 6) Delete one contact from a vendor with multiple contacts, see that the result is correct. 7) Sign off. Note: This test plan can supersede that on the previous two patches, as all functionality of the previous two patches is required by this one. Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com> Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Created attachment 31094 [details] [review] Bug 10402 [Template follow-up] Add multiple contacts for vendors This template-only follow-up tweaks the button labels and restructures the vendor view layout a little bit to make it more amenable to multiple contacts: - Add spaces after button icons - Change "Add contact" to "Add another contact" in hopes of making it less ambiguous whether clicking it will submit the whole form. - Eliminate duplicate headers on the vendor view page by making the contact name the subheading for each individual contact. To test, view details for vendors with one or more contacts, and try editing to add additional contacts. Everything should look good and work correctly. Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com> Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Created attachment 31095 [details] [review] Bug 10402 follow-up: choose contacts for claims This patch makes it possible to choose a particular contact for acquisitions and serials claims. To test: 1) Select a contact to use for claiming late orders and a contact to use for claiming late issues. 2) Send a claim for a late order and a claim for a late issue. 3) Note that the claims went out to the proper people. 4) Run the unit test with: > prove t/db_dependent/Letters.t 5) Sign off. Note: the claim messages are recorded in the logs in the *Acquisitions* module, not the Letters module as you might expect This patch also fixes several perlcritic violations and centralizes contact-related unit testing in Bookseller.t. Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Created attachment 31096 [details] [review] Bug 10402: FIX conflicts in Letters.t Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
QA comment: not blocker: On a editing a supplier with 1 contact, the "Delete contact" button will remove the contact form. It is not blocker since you can click on the "add contact" to add another contact. Still in master: 1/ The letter generated contains the <order></order> tags. 2/ The validation on claiming serials does not work (no warning/error/ok message on sending the emails). This should be done with bug 5342 (pending for 2 years...). No regression found, all works as expected. Marked as Passed QA.
Patches pushed to master. Thanks Jared! Note: some small template glitches I've seen vanished after I did ctrl+shift+r to reload CSS.
(In reply to Jonathan Druart from comment #97) > 1/ The letter generated contains the <order></order> tags. I am going to provide a patch on bug 12851.