Description
Jonathan Druart
2014-07-24 11:29:20 UTC
Created attachment 30024 [details] [review] Bug 12648: Link patrons to an order - DB changes This patch inserts the new notification template into the letters table. It also add the insert statements into the language specific files. Created attachment 30025 [details] [review] Bug 12648: Refactoring to prepare user search for reuse A previous enhancement allows to link basket with patrons. Next patches will use the same way to link order with patrons. In order to avoir c/p of code, this patch refactores this part of code. Test plan: 1/ Verify there is no regression on adding/modifying users to a basket. (acqui/basket.pl?basketno=XXX, "Managed by", "Add user"). 2/ Note that you get a friendly message if the user is already present in the list and when the user has correctly been added to the list. 3/ Note that the list uses the member search service (ie. DataTable + serverside processing). Created attachment 30026 [details] [review] Bug 12648: Link patrons to an order This patch is the main patch. This feature adds the ability to link patrons to an order. On that way, they will be notified when the order is completely received. Test plan: 1/ Execute the updatedb entry and verify you have a new notification template in your table (tools/letter.pl). code: ACQ_NOTIF_ON_RECEIV, module: acquisition 2/ You can edit it if you want 3/ Create a basket and create an order with 1 or more items 4/ Link 1+ patrons to this order 5/ Close the basket and receive the order 6/ When you have received all items for this order, all patrons attached will be notified. Check the message_queue table to check if the letters have correctly been added to the queue. Created attachment 30027 [details] [review] Bug 12648: Add unit tests for C4::Acquisition::*OrderUsers Test plan: Verify that unit tests pass with prove t/db_dependent/Acquisition/OrderUsers.t I've applied the patches against master 3.17.00.013. On adding/modifying users to a basket (acqui/basket.pl?basketno=XXX, "Managed by", "Add user"), the Search-for-patrons' Processing [opened in a new window] stops. On the contrary, on Patron module the patrons' searching is ok. On log I see: search: Template process failed: file error - .../koha-tmpl/intranet-tmpl/prog/en/modules/acqui/tables/members_results.tt: not found at .../C4/Templates.pm line 131 So I pass the patch to "Failed QA" status. The first patch "Link patrons to an order - DB changes" needs to be rebased. Created attachment 30988 [details] [review] Bug 12648: Link patrons to an order - DB changes This patch inserts the new notification template into the letters table. It also add the insert statements into the language specific files. Created attachment 30989 [details] [review] Bug 12648: Refactoring to prepare user search for reuse A previous enhancement allows to link basket with patrons. Next patches will use the same way to link order with patrons. In order to avoir c/p of code, this patch refactores this part of code. Test plan: 1/ Verify there is no regression on adding/modifying users to a basket. (acqui/basket.pl?basketno=XXX, "Managed by", "Add user"). 2/ Note that you get a friendly message if the user is already present in the list and when the user has correctly been added to the list. 3/ Note that the list uses the member search service (ie. DataTable + serverside processing). Created attachment 30990 [details] [review] Bug 12648: Link patrons to an order This patch is the main patch. This feature adds the ability to link patrons to an order. On that way, they will be notified when the order is completely received. Test plan: 1/ Execute the updatedb entry and verify you have a new notification template in your table (tools/letter.pl). code: ACQ_NOTIF_ON_RECEIV, module: acquisition 2/ You can edit it if you want 3/ Create a basket and create an order with 1 or more items 4/ Link 1+ patrons to this order 5/ Close the basket and receive the order 6/ When you have received all items for this order, all patrons attached will be notified. Check the message_queue table to check if the letters have correctly been added to the queue. Created attachment 30991 [details] [review] Bug 12648: Add unit tests for C4::Acquisition::*OrderUsers Test plan: Verify that unit tests pass with prove t/db_dependent/Acquisition/OrderUsers.t (In reply to Paola Rossi from comment #5) > On log I see: > search: Template process failed: file error - > .../koha-tmpl/intranet-tmpl/prog/en/modules/acqui/tables/members_results.tt: > not found at .../C4/Templates.pm line 131 I forgot to add 1 file :-/ Should be fixed now. Thanks, Jonathan. I've applied the patches against master 3.17.00.016. [The first patch needs to be rebased] On the patrons' search window I read: "Search for patron: Only staff with superlibrarian or acquisitions permissions (or order_manage permission if granular permissions are enabled) are returned in the search results". But some of the listed patrons are students, and so on. I add a new patron, student category, with no permission. On adding/modifying users to a basket, I can link this student to the basket. So I pass the patch to "Failed QA" status. Created attachment 31273 [details] [review] Bug 12648: The users added to basket should have a permission Before this enh, the users to add to a basket should have the acquisition.order_manage permission. This patch reintroduces this behavior. The code in acqui/add_user_search.pl was never used. The filter should be done in the members/search service. But it is not possible easily to filter using a sql query, so the filter is done after. This means that we cannot use the DT pagination (otherwise the results will become inconsistent). Test plan: 1/ On adding patrons to a basket, verify that the search patron results contain patron with the acquisition.order_manage permission. 2/ Verify that all patrons are return on the 'normal' patron search and when adding patrons to an order. (In reply to Paola Rossi from comment #11) > [The first patch needs to be rebased] It's a trivial rebase. > On the patrons' search window I read: "Search for patron: > Only staff with superlibrarian or acquisitions permissions (or order_manage > permission if granular permissions are enabled) are returned in the search > results". > > But some of the listed patrons are students, and so on. Yes, previous patches pretend to do the job but actually not at all. This last patch does it, but it's not smartly. Note for QA: I know this last patch is not the better way to do, but I don't have any other idea. Please let me know if you find another easy way to do the same job. Bug 12833 breaks this enh. Created attachment 31960 [details] [review] Bug 12648: Fix conflict with bug 12833 Created attachment 31961 [details] [review] Bug 12648: Hide the result search on load When no search has been done yet, it's not necessary to display the result list. Created attachment 32230 [details] [review] Bug 12648: The patron's name should be the same as before The displayed patron's name should be surname + firstname I've applied the 8 patches against master 3.17.00.027 [The first patch needs trivial rebase] perl t/db_dependent/Acquisition/OrderUsers.t 1..3 not ok 1 - ModOrderUsers should link patrons to an order # Failed test 'ModOrderUsers should link patrons to an order' # at t/db_dependent/Acquisition/OrderUsers.t line 76. # got: '0' # expected: '1' Use of uninitialized value in numeric gt (>) at /var/root-koha/bug-7162/C4/Acquisition.pm line 1511. ok 2 - The letter has not been sent to message queue on receiving the order, the order is not entire received Use of uninitialized value in numeric gt (>) at /var/root-koha/bug-7162/C4/Acquisition.pm line 1511. not ok 3 - The letter has been sent to message queue on receiving the order # Failed test 'The letter has been sent to message queue on receiving the order' # at t/db_dependent/Acquisition/OrderUsers.t line 108. # got: '0' # expected: '1' # Looks like you failed 2 tests of 3. So I pass the patch to "Failed QA" status. Created attachment 33186 [details] [review] Bug 12648: Link patrons to an order - DB changes This patch inserts the new notification template into the letters table. It also add the insert statements into the language specific files. Created attachment 33187 [details] [review] Bug 12648: Refactoring to prepare user search for reuse A previous enhancement allows to link basket with patrons. Next patches will use the same way to link order with patrons. In order to avoir c/p of code, this patch refactores this part of code. Test plan: 1/ Verify there is no regression on adding/modifying users to a basket. (acqui/basket.pl?basketno=XXX, "Managed by", "Add user"). 2/ Note that you get a friendly message if the user is already present in the list and when the user has correctly been added to the list. 3/ Note that the list uses the member search service (ie. DataTable + serverside processing). Created attachment 33188 [details] [review] Bug 12648: Link patrons to an order This patch is the main patch. This feature adds the ability to link patrons to an order. On that way, they will be notified when the order is completely received. Test plan: 1/ Execute the updatedb entry and verify you have a new notification template in your table (tools/letter.pl). code: ACQ_NOTIF_ON_RECEIV, module: acquisition 2/ You can edit it if you want 3/ Create a basket and create an order with 1 or more items 4/ Link 1+ patrons to this order 5/ Close the basket and receive the order 6/ When you have received all items for this order, all patrons attached will be notified. Check the message_queue table to check if the letters have correctly been added to the queue. Created attachment 33189 [details] [review] Bug 12648: Add unit tests for C4::Acquisition::*OrderUsers Test plan: Verify that unit tests pass with prove t/db_dependent/Acquisition/OrderUsers.t Created attachment 33190 [details] [review] Bug 12648: The users added to basket should have a permission Before this enh, the users to add to a basket should have the acquisition.order_manage permission. This patch reintroduces this behavior. The code in acqui/add_user_search.pl was never used. The filter should be done in the members/search service. But it is not possible easily to filter using a sql query, so the filter is done after. This means that we cannot use the DT pagination (otherwise the results will become inconsistent). Test plan: 1/ On adding patrons to a basket, verify that the search patron results contain patron with the acquisition.order_manage permission. 2/ Verify that all patrons are return on the 'normal' patron search and when adding patrons to an order. Created attachment 33191 [details] [review] Bug 12648: Fix conflict with bug 12833 Created attachment 33192 [details] [review] Bug 12648: Hide the result search on load When no search has been done yet, it's not necessary to display the result list. Created attachment 33193 [details] [review] Bug 12648: The patron's name should be the same as before The displayed patron's name should be surname + firstname (In reply to Paola Rossi from comment #18) > # Looks like you failed 2 tests of 3. I don't get these failures, could you please retest with this new rebased patch set? I've tried to apply the patches agaist master 3.19.00.000 [The first patch needed a trivial rebase.] At the six-th patch: Applying: Bug 12648: Fix conflict with bug 12833 fatal: sha1 information is lacking or useless (svc/members/search). Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001 Bug 12648: Fix conflict with bug 12833 So I pass the patch to "Patch doesn't apply" status. Created attachment 34224 [details] [review] Bug 12648: Link patrons to an order - DB changes This patch inserts the new notification template into the letters table. It also add the insert statements into the language specific files. Created attachment 34225 [details] [review] Bug 12648: Refactoring to prepare user search for reuse A previous enhancement allows to link basket with patrons. Next patches will use the same way to link order with patrons. In order to avoir c/p of code, this patch refactores this part of code. Test plan: 1/ Verify there is no regression on adding/modifying users to a basket. (acqui/basket.pl?basketno=XXX, "Managed by", "Add user"). 2/ Note that you get a friendly message if the user is already present in the list and when the user has correctly been added to the list. 3/ Note that the list uses the member search service (ie. DataTable + serverside processing). Created attachment 34226 [details] [review] Bug 12648: Link patrons to an order This patch is the main patch. This feature adds the ability to link patrons to an order. On that way, they will be notified when the order is completely received. Test plan: 1/ Execute the updatedb entry and verify you have a new notification template in your table (tools/letter.pl). code: ACQ_NOTIF_ON_RECEIV, module: acquisition 2/ You can edit it if you want 3/ Create a basket and create an order with 1 or more items 4/ Link 1+ patrons to this order 5/ Close the basket and receive the order 6/ When you have received all items for this order, all patrons attached will be notified. Check the message_queue table to check if the letters have correctly been added to the queue. Created attachment 34227 [details] [review] Bug 12648: Add unit tests for C4::Acquisition::*OrderUsers Test plan: Verify that unit tests pass with prove t/db_dependent/Acquisition/OrderUsers.t Created attachment 34228 [details] [review] Bug 12648: The users added to basket should have a permission Before this enh, the users to add to a basket should have the acquisition.order_manage permission. This patch reintroduces this behavior. The code in acqui/add_user_search.pl was never used. The filter should be done in the members/search service. But it is not possible easily to filter using a sql query, so the filter is done after. This means that we cannot use the DT pagination (otherwise the results will become inconsistent). Test plan: 1/ On adding patrons to a basket, verify that the search patron results contain patron with the acquisition.order_manage permission. 2/ Verify that all patrons are return on the 'normal' patron search and when adding patrons to an order. Created attachment 34229 [details] [review] Bug 12648: Fix conflict with bug 12833 Created attachment 34230 [details] [review] Bug 12648: Hide the result search on load When no search has been done yet, it's not necessary to display the result list. Created attachment 34231 [details] [review] Bug 12648: The patron's name should be the same as before The displayed patron's name should be surname + firstname Patches rebased. I've applied the patches against master 3.19.00.000 About : >Test plan: >1/ Execute the updatedb entry and verify you have a new notification template in your table (tools/letter.pl). >code: ACQ_NOTIF_ON_RECEIV, module: acquisition I saw that the module is acquisition, OK >2/ You can edit it if you want I saw that the "Koha module" is "Catalog" ERROR, while "Acquisition" is not an available option in the drop down list. On MASTER, in effect, the available modules are 8, and none of them is "Acquisition". So I pass the patch to "Failed QA" status. Created attachment 34477 [details] [review] Bug 12648: Add the new 'Acquisition' entry in the letter module list (In reply to Paola Rossi from comment #38) > >2/ You can edit it if you want > > I saw that the "Koha module" is "Catalog" ERROR, while "Acquisition" is not > an available option in the drop down list. > > On MASTER, in effect, the available modules are 8, and none of them is > "Acquisition". > > So I pass the patch to "Failed QA" status. Sorry about that. It should be fixed now. Created attachment 34487 [details] [review] Bug 12648: Link patrons to an order - DB changes Thanks, Jonathan. I've applied the patches against master 3.19.00.000 IMO everything is OK as required. So I pass the patch to "Signed Off" status. Only [certain] staff patrons could be linked to a basket, whilest patrons of all categories could be linked to an order. When the pop-up to "Add users" was opened, no user was shown [OK] as required. And then, if I submitted with no search value, all the [allowed] users were listed [OK]. Newing [or modifying] an order, in "Patrons" tag, next to "To notify on reveiving:", I saw firstname + surname of the added users [OK]. In the message_queue records, in "content" field, I see "Dear firstname + surname ..." [OK]. In the patrons' list, I see "surname, firstname" datas in "Name" column [OK]. Created attachment 34488 [details] [review] Bug 12648: Refactoring to prepare user search for reuse Created attachment 34489 [details] [review] Bug 12648: Link patrons to an order Created attachment 34490 [details] [review] Bug 12648: Add unit tests for C4::Acquisition::*OrderUsers Created attachment 34491 [details] [review] Bug 12648: The users added to basket should have a permission Created attachment 34492 [details] [review] Bug 12648: Fix conflict with bug 12833 Created attachment 34493 [details] [review] Bug 12648: Hide the result search on load Created attachment 34494 [details] [review] Bug 12648: The patron's name should be the same as before Created attachment 34495 [details] [review] Bug 12648: Add the new 'Acquisition' entry in the letter module list Created attachment 35056 [details] [review] [PASSED QA] Bug 12648: Link patrons to an order This patch is the main patch. This feature adds the ability to link patrons to an order. On that way, they will be notified when the order is completely received. Test plan: 1/ Execute the updatedb entry and verify you have a new notification template in your table (tools/letter.pl). code: ACQ_NOTIF_ON_RECEIV, module: acquisition 2/ You can edit it if you want 3/ Create a basket and create an order with 1 or more items 4/ Link 1+ patrons to this order 5/ Close the basket and receive the order 6/ When you have received all items for this order, all patrons attached will be notified. Check the message_queue table to check if the letters have correctly been added to the queue. Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Created attachment 35058 [details] [review] [PASSED QA] Bug 12648: Link patrons to an order This patch is the main patch. This feature adds the ability to link patrons to an order. On that way, they will be notified when the order is completely received. Test plan: 1/ Execute the updatedb entry and verify you have a new notification template in your table (tools/letter.pl). code: ACQ_NOTIF_ON_RECEIV, module: acquisition 2/ You can edit it if you want 3/ Create a basket and create an order with 1 or more items 4/ Link 1+ patrons to this order 5/ Close the basket and receive the order 6/ When you have received all items for this order, all patrons attached will be notified. Check the message_queue table to check if the letters have correctly been added to the queue. Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Created attachment 35059 [details] [review] [PASSED QA] Bug 12648: Link patrons to an order This patch is the main patch. This feature adds the ability to link patrons to an order. On that way, they will be notified when the order is completely received. Test plan: 1/ Execute the updatedb entry and verify you have a new notification template in your table (tools/letter.pl). code: ACQ_NOTIF_ON_RECEIV, module: acquisition 2/ You can edit it if you want 3/ Create a basket and create an order with 1 or more items 4/ Link 1+ patrons to this order 5/ Close the basket and receive the order 6/ When you have received all items for this order, all patrons attached will be notified. Check the message_queue table to check if the letters have correctly been added to the queue. Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Created attachment 35060 [details] [review] [PASSED QA] Bug 12648: Add unit tests for C4::Acquisition::*OrderUsers Test plan: Verify that unit tests pass with prove t/db_dependent/Acquisition/OrderUsers.t Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Created attachment 35061 [details] [review] [PASSED QA] Bug 12648: The users added to basket should have a permission Before this enh, the users to add to a basket should have the acquisition.order_manage permission. This patch reintroduces this behavior. The code in acqui/add_user_search.pl was never used. The filter should be done in the members/search service. But it is not possible easily to filter using a sql query, so the filter is done after. This means that we cannot use the DT pagination (otherwise the results will become inconsistent). Test plan: 1/ On adding patrons to a basket, verify that the search patron results contain patron with the acquisition.order_manage permission. 2/ Verify that all patrons are return on the 'normal' patron search and when adding patrons to an order. Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Created attachment 35062 [details] [review] [PASSED QA] Bug 12648: Fix conflict with bug 12833 Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Created attachment 35063 [details] [review] [PASSED QA] Bug 12648: Hide the result search on load When no search has been done yet, it's not necessary to display the result list. Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Created attachment 35064 [details] [review] [PASSED QA] Bug 12648: The patron's name should be the same as before The displayed patron's name should be surname + firstname Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Created attachment 35065 [details] [review] [PASSED QA] Bug 12648: Add the new 'Acquisition' entry in the letter module list Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Created attachment 35066 [details] [review] Bug 12648 - QA Followup I like this! Should we add a default letter (separate bug)? (In reply to Katrin Fischer from comment #60) > I like this! Should we add a default letter (separate bug)? The patch existed but it has been obsoleted (certainly a mistake). I reintroduced it. Jonathan, I like the patch set, but there are two minor things remaining: - Missing the kohastructure.sql addition - We should really stick with the adopted naming schema for tables. Even if it will not be consistent with the current table names for acquisitions (we should, at some point just rename them). I would accept 'aqorder_users', but the ideal one would be 'aquisition_order_users', that would map to Koha::Acquisition::Order::Users. I'm open to discussing the naming schema and I know this bug has been here before the guidelines have been accepted. It is just a minor refactoring that i will accept as PASSED-QA. Thanks! Created attachment 36795 [details] [review] Bug 12648: Link patrons to an order - DB changes This patch inserts the new notification template into the letters table. It also add the insert statements into the language specific files. Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Amended patch: Add the kohastructure.sql changes Created attachment 36796 [details] [review] Bug 12648: Refactoring to prepare user search for reuse A previous enhancement allows to link basket with patrons. Next patches will use the same way to link order with patrons. In order to avoir c/p of code, this patch refactores this part of code. Test plan: 1/ Verify there is no regression on adding/modifying users to a basket. (acqui/basket.pl?basketno=XXX, "Managed by", "Add user"). 2/ Note that you get a friendly message if the user is already present in the list and when the user has correctly been added to the list. 3/ Note that the list uses the member search service (ie. DataTable + serverside processing). Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Created attachment 36797 [details] [review] Bug 12648: Link patrons to an order This patch is the main patch. This feature adds the ability to link patrons to an order. On that way, they will be notified when the order is completely received. Test plan: 1/ Execute the updatedb entry and verify you have a new notification template in your table (tools/letter.pl). code: ACQ_NOTIF_ON_RECEIV, module: acquisition 2/ You can edit it if you want 3/ Create a basket and create an order with 1 or more items 4/ Link 1+ patrons to this order 5/ Close the basket and receive the order 6/ When you have received all items for this order, all patrons attached will be notified. Check the message_queue table to check if the letters have correctly been added to the queue. Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Created attachment 36798 [details] [review] Bug 12648: Add unit tests for C4::Acquisition::*OrderUsers Test plan: Verify that unit tests pass with prove t/db_dependent/Acquisition/OrderUsers.t Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Created attachment 36799 [details] [review] Bug 12648: The users added to basket should have a permission Before this enh, the users to add to a basket should have the acquisition.order_manage permission. This patch reintroduces this behavior. The code in acqui/add_user_search.pl was never used. The filter should be done in the members/search service. But it is not possible easily to filter using a sql query, so the filter is done after. This means that we cannot use the DT pagination (otherwise the results will become inconsistent). Test plan: 1/ On adding patrons to a basket, verify that the search patron results contain patron with the acquisition.order_manage permission. 2/ Verify that all patrons are return on the 'normal' patron search and when adding patrons to an order. Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Created attachment 36800 [details] [review] Bug 12648: Fix conflict with bug 12833 Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Created attachment 36801 [details] [review] Bug 12648: Hide the result search on load When no search has been done yet, it's not necessary to display the result list. Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Created attachment 36802 [details] [review] Bug 12648: The patron's name should be the same as before The displayed patron's name should be surname + firstname Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Created attachment 36803 [details] [review] Bug 12648: Add the new 'Acquisition' entry in the letter module list Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Created attachment 36804 [details] [review] Bug 12648 - QA Followup Created attachment 36805 [details] [review] Bug 12648: Rename aqorderusers to aqorder_users (In reply to Tomás Cohen Arazi from comment #62) > - Missing the kohastructure.sql addition First patch amended. > - We should really stick with the adopted naming schema for tables. Even if > it will not be consistent with the current table names for acquisitions (we > should, at some point just rename them). > > I would accept 'aqorder_users', but the ideal one would be > 'aquisition_order_users', that would map to Koha::Acquisition::Order::Users. aqorderusers replaced with aqorders_users in the last patch. Created attachment 36807 [details] [review] Bug 12648: (RM followup) DBIx schema update Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com> Created attachment 36810 [details] [review] Bug 12648: Fix conflict with bug 8096 Created attachment 36817 [details] [review] Bug 12648: Add some documentation on the kohastructure.sql file Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com> Patches pushed to master. Good job Jonathan! I'm not finding any reference to this feature in the manual. Is it there? (In reply to Christopher Brannon from comment #79) > I'm not finding any reference to this feature in the manual. Is it there? CCing Nicole. (In reply to Jonathan Druart from comment #80) > (In reply to Christopher Brannon from comment #79) > > I'm not finding any reference to this feature in the manual. Is it there? > > CCing Nicole. It's in a screenshot but not in words. Adding it now. I lied - it was there: "With any of the above ordering options you're presented with an option to notify patrons of the new item when it's received. The contents of that notification can be edited in the Notices & Slips tool and will have the code of ACQ_NOTIF_ON_RECEIV. In the 'Patrons' section you will see an option to 'Add user'. Click that button to add patrons who will be notified of the new issue. " (In reply to Nicole C. Engard from comment #82) > I lied - it was there: > > "With any of the above ordering options you're presented with an option to > notify patrons of the new item when it's received. The contents of that > notification can be edited in the Notices & Slips tool and will have the > code of ACQ_NOTIF_ON_RECEIV. In the 'Patrons' section you will see an option > to 'Add user'. Click that button to add patrons who will be notified of the > new issue. " Ah! It was way down there. I assumed it would be under the first picture that shows it. Thanks! Christopher Am I missing something, or is it impossible to tell what patrons are linked to an order after that order is placed? I can find them using 'select * from aqorder_users', but not through the UI... (In reply to David Cook from comment #84) > Am I missing something, or is it impossible to tell what patrons are linked > to an order after that order is placed? > > I can find them using 'select * from aqorder_users', but not through the > UI... I think the problem is that we miss a "view" of the full order information after the basket has been closed. We only have an edit one. See: bug 31423 |