It would be helpful to add the option to assign tickets to librarians for the catalog concerns feature. This is especially helpful for the future of this development in regard to using it as a framework for a full ticketing/enquiry management system/module.
Notes to self.. this has a few different API options. * `PUT /tickets/{ticket_id}` where we just update an `assignee_id` field directly * `POST /tickets/{ticket_id}/updates` where we add an `assignee_id` field into the update and sync that across to the tickets table too (this allows for tracking of when, who, message etc at the same time) * Supporting both of the above, and ensuring two-way sync such that a POST to /updates sets the ticket.assignee_id but also a PUT to /tickets with a new assignee_id also adds a new ticket_update including the who, when but no message. My gut it telling me to go with the last option, allowing for updates via the modal and also quick assignee updates via action buttons in the main table.
Created attachment 160365 [details] [review] Bug 35657: Add assignee_id to tickets and ticket_updates This patch updates the tickets and ticket_updates tables to include a assignee_id.
Created attachment 160366 [details] [review] Bug 35657: Schema
Created attachment 160367 [details] [review] Bug 35657: Add support for assignee_id to ticket_updates endpoint This patch starts to add support for cross-synced ticket.assignee_id updates. You should be able to either set assignee at the time of adding a ticket_update or directly on the ticket.. but in both cases end up with a ticket_update with the fine details of when and who set the assigee.
Created attachment 160368 [details] [review] Bug 35657: Add option to set assignee during update
Created attachment 160369 [details] [review] Bug 35657: Display assignee under 'Status' column
Still a work in progress here..
Created attachment 160372 [details] [review] Bug 35657: Add assignee_id to tickets and ticket_updates This patch updates the tickets and ticket_updates tables to include a assignee_id.
Created attachment 160373 [details] [review] Bug 35657: Schema
Created attachment 160374 [details] [review] Bug 35657: Add support for assignee_id to ticket_updates endpoint This patch starts to add support for cross-synced ticket.assignee_id updates. You should be able to either set assignee at the time of adding a ticket_update or directly on the ticket.. but in both cases end up with a ticket_update with the fine details of when and who set the assigee.
Created attachment 160375 [details] [review] Bug 35657: Add option to set assignee during update
Created attachment 160376 [details] [review] Bug 35657: Display assignee under 'Status' column
Created attachment 160377 [details] [review] Bug 35657: Display assignee under updates
I am eagerly hoping this feature is added to Cataloging Concerns! Thanks for working on this. - Chelsea
Created attachment 164923 [details] [review] Bug 35657: Add assignee_id to tickets and ticket_updates This patch updates the tickets and ticket_updates tables to include a assignee_id.
Created attachment 164924 [details] [review] Bug 35657: Schema
Created attachment 164925 [details] [review] Bug 35657: Add support for assignee_id to ticket_updates endpoint This patch starts to add support for cross-synced ticket.assignee_id updates. You should be able to either set assignee at the time of adding a ticket_update or directly on the ticket.. but in both cases end up with a ticket_update with the fine details of when and who set the assigee.
Created attachment 164926 [details] [review] Bug 35657: Add option to set assignee during update
Created attachment 164927 [details] [review] Bug 35657: Display assignee under 'Status' column
Created attachment 164928 [details] [review] Bug 35657: Display assignee under updates
Branch fully rebased so this should be simple enough to test now :)
Created attachment 164932 [details] [review] Bug 35657: Add assignee_id to tickets and ticket_updates This patch updates the tickets and ticket_updates tables to include a assignee_id.
Created attachment 164933 [details] [review] Bug 35657: Schema update
Created attachment 164934 [details] [review] Bug 35657: Add support for assignee_id to ticket_updates endpoint This patch adds support for cross-synced ticket.assignee_id updates. The API allows you to set assignee directly on a ticket or via a ticket_update. In both cases we store a ticket_update with the fine details of when and who set the assigee.
Created attachment 164935 [details] [review] Bug 35657: Add option to set assignee during update This patch exposes the UI to allow setting assignee from the ticket update modal. Test plan 1) Apply the patches and run the database updates 2) Enable catalog concerns - `CatalogConcerns` or `OPACCatalogConcerns` 3) Submit a catalog concern via the OPAC or Staff client biblio page 4) Navigate to the concerns management page 'Cataloging > Catalog concerns' 5) Note there is no assignee displayed in the status field for your new concern. 6) Click the concern to view it's details 7) Note that in the modal there is now a new 'Change assignee' option 8) Use this new option to search for and assign a librarian to the concern. 9) Submit the update 10) Your assignee should now appear in the 'status' data field in the table 11) Clicking through to details again, you should see when the assignee was set and should also be able to re-assign it
Sorry, there's one problem: When creating a concern from the OPAC w/ an account that doesn't have an email address associated, we get: [2024/04/16 14:24:29] [WARN] FAIL: No 'to_address', email address or guarantors email address for borrowernumber (51) at /kohadevbox/koha/C4/Letters.pm line 1366. Also there's a stack trace in ktd when you set an email address for the `koha` user, but I wrote that off as related to ktd. That's fine and there's also an error message displayed to the user: > There was an error when submitting your concern, please contact a librarian. The problem is that that concern still goes through and is visible in the associated concerns for that biblio. Of course the feature works but could you still fix that before the sign-off. Maybe either - block the concern from going through - use a more descriptive error message
Interesting bug you've found there.. thanks. I'm contemplating whether that's important enough to warrant fixing on it's own bug of just dealing with it inline here.... think I'll cmull it over on the school run.
If you decide to move that bug outside of the scope of this one and make it dependent on the new one, we could certainly move this one forward, right?
OK.. I added it as it's own bug as it's unrelated to this one and should certainly be backported as a bugfix. Please see bug 36612
The warn in C4::Letters appears to be deliberate.. though it's rather noisy.. I reckon that should also go on it's own bug some time to clean up the warns.. the details are now reported in the UI anyway so the warns are a bit superflous.
Will do a sign-off tomorrow.
Created attachment 164974 [details] [review] Bug 35657: Add assignee_id to tickets and ticket_updates This patch updates the tickets and ticket_updates tables to include a assignee_id. Signed-off-by: Paul Derscheid <paulderscheid@gmail.com>
Created attachment 164975 [details] [review] Bug 35657: Schema update Signed-off-by: Paul Derscheid <paulderscheid@gmail.com>
Created attachment 164976 [details] [review] Bug 35657: Add support for assignee_id to ticket_updates endpoint This patch adds support for cross-synced ticket.assignee_id updates. The API allows you to set assignee directly on a ticket or via a ticket_update. In both cases we store a ticket_update with the fine details of when and who set the assigee. Signed-off-by: Paul Derscheid <paulderscheid@gmail.com>
Created attachment 164977 [details] [review] Bug 35657: Add option to set assignee during update This patch exposes the UI to allow setting assignee from the ticket update modal. Test plan 1) Apply the patches and run the database updates 2) Enable catalog concerns - `CatalogConcerns` or `OPACCatalogConcerns` 3) Submit a catalog concern via the OPAC or Staff client biblio page 4) Navigate to the concerns management page 'Cataloging > Catalog concerns' 5) Note there is no assignee displayed in the status field for your new concern. 6) Click the concern to view it's details 7) Note that in the modal there is now a new 'Change assignee' option 8) Use this new option to search for and assign a librarian to the concern. 9) Submit the update 10) Your assignee should now appear in the 'status' data field in the table 11) Clicking through to details again, you should see when the assignee was set and should also be able to re-assign it Signed-off-by: Paul Derscheid <paulderscheid@gmail.com>
[2024/04/26 07:34:03] [ERROR] GET /api/v1/tickets: unhandled exception (DBIx::Class::Exception)<<DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Unknown column 'me.assignee_id' in 'field list' at /usr/share/koha/Koha/Objects.pm line 399>>
No unit tests here?
(In reply to Marcel de Rooy from comment #36) > [2024/04/26 07:34:03] [ERROR] GET /api/v1/tickets: unhandled exception > (DBIx::Class::Exception)<<DBIx::Class::Storage::DBI::_dbh_execute(): DBI > Exception: DBD::mysql::st execute failed: Unknown column 'me.assignee_id' in > 'field list' at /usr/share/koha/Koha/Objects.pm line 399>> A 500 when loading the staff detail page for a biblio with concerns. Hmm, this concerns me :)
Definitely needs Unit tests.. I clearly forgot to attach those.. I'll go dig out the branch and get them submitted. As for your 500 Error.. I think that's a missing DB update..
Created attachment 165666 [details] [review] Bug 35657: Add assignee_id to tickets and ticket_updates This patch updates the tickets and ticket_updates tables to include a assignee_id.
Created attachment 165667 [details] [review] Bug 35657: Schema update
Created attachment 165668 [details] [review] Bug 35657: Add support for assignee_id to ticket_updates endpoint This patch adds support for cross-synced ticket.assignee_id updates. The API allows you to set assignee directly on a ticket or via a ticket_update. In both cases we store a ticket_update with the fine details of when and who set the assigee.
Created attachment 165669 [details] [review] Bug 35657: Add option to set assignee during update This patch exposes the UI to allow setting assignee from the ticket update modal. Test plan 1) Apply the patches and run the database updates 2) Enable catalog concerns - `CatalogConcerns` or `OPACCatalogConcerns` 3) Submit a catalog concern via the OPAC or Staff client biblio page 4) Navigate to the concerns management page 'Cataloging > Catalog concerns' 5) Note there is no assignee displayed in the status field for your new concern. 6) Click the concern to view it's details 7) Note that in the modal there is now a new 'Change assignee' option 8) Use this new option to search for and assign a librarian to the concern. 9) Submit the update 10) Your assignee should now appear in the 'status' data field in the table 11) Clicking through to details again, you should see when the assignee was set and should also be able to re-assign it
Created attachment 165670 [details] [review] Bug 35657: Unit tests for relation accessor additions This patch adds the unit tests for the new 'assignee' relation accessors added to Koha::Ticket and Koha::Ticket::Update classes.
Created attachment 165671 [details] [review] Bug 35657: Unit tests for ticket_update api addition This patch adds unit tests for the addition of assignee handling in the ticket update endpoint
Created attachment 165672 [details] [review] Bug 35657: Unit test for addition to tickets endpoint This patch adds a unit test for the additional option of now setting the assignee from the tickets update endpoint.
Created attachment 165673 [details] [review] Bug 35657: Add assignee_id to tickets and ticket_updates This patch updates the tickets and ticket_updates tables to include a assignee_id. Signed-off-by: Paul Derscheid <paulderscheid@gmail.com>
Created attachment 165674 [details] [review] Bug 35657: Schema update Signed-off-by: Paul Derscheid <paulderscheid@gmail.com>
Created attachment 165675 [details] [review] Bug 35657: Add support for assignee_id to ticket_updates endpoint This patch adds support for cross-synced ticket.assignee_id updates. The API allows you to set assignee directly on a ticket or via a ticket_update. In both cases we store a ticket_update with the fine details of when and who set the assigee. Signed-off-by: Paul Derscheid <paulderscheid@gmail.com>
Created attachment 165676 [details] [review] Bug 35657: Add option to set assignee during update This patch exposes the UI to allow setting assignee from the ticket update modal. Test plan 1) Apply the patches and run the database updates 2) Enable catalog concerns - `CatalogConcerns` or `OPACCatalogConcerns` 3) Submit a catalog concern via the OPAC or Staff client biblio page 4) Navigate to the concerns management page 'Cataloging > Catalog concerns' 5) Note there is no assignee displayed in the status field for your new concern. 6) Click the concern to view it's details 7) Note that in the modal there is now a new 'Change assignee' option 8) Use this new option to search for and assign a librarian to the concern. 9) Submit the update 10) Your assignee should now appear in the 'status' data field in the table 11) Clicking through to details again, you should see when the assignee was set and should also be able to re-assign it Signed-off-by: Paul Derscheid <paulderscheid@gmail.com>
Created attachment 165677 [details] [review] Bug 35657: Unit tests for relation accessor additions This patch adds the unit tests for the new 'assignee' relation accessors added to Koha::Ticket and Koha::Ticket::Update classes. Signed-off-by: Paul Derscheid <paulderscheid@gmail.com>
Created attachment 165678 [details] [review] Bug 35657: Unit tests for ticket_update api addition This patch adds unit tests for the addition of assignee handling in the ticket update endpoint Signed-off-by: Paul Derscheid <paulderscheid@gmail.com>
Created attachment 165679 [details] [review] Bug 35657: Unit test for addition to tickets endpoint This patch adds a unit test for the additional option of now setting the assignee from the tickets update endpoint. Signed-off-by: Paul Derscheid <paulderscheid@gmail.com>
Unit tests added.. pretty sure you had just missed running updatedatebase as I can't replicate the 500 error. :)
Created attachment 165786 [details] [review] Bug 35657: Add assignee_id to tickets and ticket_updates This patch updates the tickets and ticket_updates tables to include a assignee_id. Signed-off-by: Paul Derscheid <paulderscheid@gmail.com>
Created attachment 165787 [details] [review] Bug 35657: Schema update Signed-off-by: Paul Derscheid <paulderscheid@gmail.com>
Created attachment 165788 [details] [review] Bug 35657: Add support for assignee_id to ticket_updates endpoint This patch adds support for cross-synced ticket.assignee_id updates. The API allows you to set assignee directly on a ticket or via a ticket_update. In both cases we store a ticket_update with the fine details of when and who set the assigee. Signed-off-by: Paul Derscheid <paulderscheid@gmail.com>
Created attachment 165789 [details] [review] Bug 35657: Add option to set assignee during update This patch exposes the UI to allow setting assignee from the ticket update modal. Test plan 1) Apply the patches and run the database updates 2) Enable catalog concerns - `CatalogConcerns` or `OPACCatalogConcerns` 3) Submit a catalog concern via the OPAC or Staff client biblio page 4) Navigate to the concerns management page 'Cataloging > Catalog concerns' 5) Note there is no assignee displayed in the status field for your new concern. 6) Click the concern to view it's details 7) Note that in the modal there is now a new 'Change assignee' option 8) Use this new option to search for and assign a librarian to the concern. 9) Submit the update 10) Your assignee should now appear in the 'status' data field in the table 11) Clicking through to details again, you should see when the assignee was set and should also be able to re-assign it Signed-off-by: Paul Derscheid <paulderscheid@gmail.com>
Created attachment 165790 [details] [review] Bug 35657: Unit tests for relation accessor additions This patch adds the unit tests for the new 'assignee' relation accessors added to Koha::Ticket and Koha::Ticket::Update classes. Signed-off-by: Paul Derscheid <paulderscheid@gmail.com>
Created attachment 165791 [details] [review] Bug 35657: Unit tests for ticket_update api addition This patch adds unit tests for the addition of assignee handling in the ticket update endpoint Signed-off-by: Paul Derscheid <paulderscheid@gmail.com>
Created attachment 165792 [details] [review] Bug 35657: Unit test for addition to tickets endpoint This patch adds a unit test for the additional option of now setting the assignee from the tickets update endpoint. Signed-off-by: Paul Derscheid <paulderscheid@gmail.com>
Just another rebase since the prettier stuff got in... would really love to see this make release.
Having another look here
(In reply to Martin Renvoize from comment #54) > Unit tests added.. pretty sure you had just missed running updatedatebase as > I can't replicate the 500 error. > > :) Please explain that to me. There is no dbrev in this patch set ! LOL Paul: How did you test it ?
Created attachment 165878 [details] [review] Bug 35657: (follow-up) Add missing DB update
Can't believe I somehow missed attaching the DB update in the first commit!.. It's there now in the follow-up.. we can squash that of course.. just didn't fancy uploading all the patches again for the rebase.
Marcel: just followed the initial test plan (the one marked as important).
Created attachment 165879 [details] [review] Bug 35657: Add assignee_id to tickets and ticket_updates This patch updates the tickets and ticket_updates tables to include a assignee_id. Signed-off-by: Paul Derscheid <paulderscheid@gmail.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 165880 [details] [review] Bug 35657: Schema update Signed-off-by: Paul Derscheid <paulderscheid@gmail.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 165881 [details] [review] Bug 35657: Add support for assignee_id to ticket_updates endpoint This patch adds support for cross-synced ticket.assignee_id updates. The API allows you to set assignee directly on a ticket or via a ticket_update. In both cases we store a ticket_update with the fine details of when and who set the assigee. Signed-off-by: Paul Derscheid <paulderscheid@gmail.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 165882 [details] [review] Bug 35657: Add option to set assignee during update This patch exposes the UI to allow setting assignee from the ticket update modal. Test plan 1) Apply the patches and run the database updates 2) Enable catalog concerns - `CatalogConcerns` or `OPACCatalogConcerns` 3) Submit a catalog concern via the OPAC or Staff client biblio page 4) Navigate to the concerns management page 'Cataloging > Catalog concerns' 5) Note there is no assignee displayed in the status field for your new concern. 6) Click the concern to view it's details 7) Note that in the modal there is now a new 'Change assignee' option 8) Use this new option to search for and assign a librarian to the concern. 9) Submit the update 10) Your assignee should now appear in the 'status' data field in the table 11) Clicking through to details again, you should see when the assignee was set and should also be able to re-assign it Signed-off-by: Paul Derscheid <paulderscheid@gmail.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 165883 [details] [review] Bug 35657: Unit tests for relation accessor additions This patch adds the unit tests for the new 'assignee' relation accessors added to Koha::Ticket and Koha::Ticket::Update classes. Signed-off-by: Paul Derscheid <paulderscheid@gmail.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 165884 [details] [review] Bug 35657: Unit tests for ticket_update api addition This patch adds unit tests for the addition of assignee handling in the ticket update endpoint Signed-off-by: Paul Derscheid <paulderscheid@gmail.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 165885 [details] [review] Bug 35657: Unit test for addition to tickets endpoint This patch adds a unit test for the additional option of now setting the assignee from the tickets update endpoint. Signed-off-by: Paul Derscheid <paulderscheid@gmail.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 165886 [details] [review] Bug 35657: (follow-up) Add missing DB update Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
WARN t/db_dependent/api/v1/ticket_updates.t WARN tidiness The file is less tidy than before (bad/messy lines before: 58, now: 80) WARN t/db_dependent/api/v1/tickets.t WARN tidiness The file is less tidy than before (bad/messy lines before: 65, now: 70) Status is updated on cataloguing/concerns.pl, but not on detail page ? I cannot add an assignee without changing the status ? I resolved a concern and wanted to revert its status again. Ending up in ticket status RESO02 but update has ST01 again. See tables below. I wont block this patch set as part of this tree. But still feel that the functionality is not clear and the forms are not completely bug free. Add experimental status? MariaDB [koha_myclone]> select * from tickets; +----+---------+-------------+---------------------+--------+---------------------+--------+-------------+-------------+---------------------+-----------+ | id | source | reporter_id | reported_date | title | body | status | assignee_id | resolver_id | resolved_date | biblio_id | +----+---------+-------------+---------------------+--------+---------------------+--------+-------------+-------------+---------------------+-----------+ | 34 | catalog | 51 | 2024-04-26 06:51:06 | test | This is my concern. | ST01 | 30 | 51 | 2024-04-30 13:29:57 | 1 | | 35 | catalog | 51 | 2024-04-26 06:52:50 | Second | Test | RESO2 | NULL | 51 | 2024-04-26 07:14:14 | 1 | +----+---------+-------------+---------------------+--------+---------------------+--------+-------------+-------------+---------------------+-----------+ MariaDB [koha_myclone]> select * from ticket_updates; +----+-----------+---------+-------------+--------+---------------------+----------+--------+ | id | ticket_id | user_id | assignee_id | public | date | message | status | +----+-----------+---------+-------------+--------+---------------------+----------+--------+ | 13 | 34 | 51 | NULL | 0 | 2024-04-26 06:53:04 | Update 1 | NULL | | 14 | 34 | 51 | NULL | 0 | 2024-04-26 06:54:36 | | ST01 | | 22 | 35 | 51 | NULL | 0 | 2024-04-26 07:14:14 | | RESO2 | | 32 | 34 | 51 | 19 | 0 | 2024-04-30 13:24:34 | | ST01 | | 33 | 34 | 51 | 30 | 0 | 2024-04-30 13:29:27 | | ST01 | | 34 | 34 | 51 | NULL | 0 | 2024-04-30 13:29:57 | | RESO2 | | 35 | 34 | 51 | 30 | 0 | 2024-04-30 13:30:09 | | ST01 | +----+-----------+---------+-------------+--------+---------------------+----------+--------+ Passed QA
I can't do more for today, but I will still review this for 24.05 end of the week.
I'd be more than happy with experimental and I will refine as bugfixes during the first month of the next cycle if that works for people?
Created attachment 166067 [details] [review] Bug 35657: (follow-up) Placeholders should be translatable Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Pushed for 24.05! Well done everyone, thank you!
Not backported to 23.11.x