Bug 14843 - Notifications and messages via REST API
Summary: Notifications and messages via REST API
Status: Patch doesn't apply
Alias: None
Product: Koha
Classification: Unclassified
Component: REST API (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Lari Taskula
QA Contact:
URL:
Keywords: needs_rfc
Depends on: 7174 12426 13799 14723 18206
Blocks: 14767 14855
  Show dependency treegraph
 
Reported: 2015-09-17 09:52 UTC by Lari Taskula
Modified: 2020-11-10 10:54 UTC (History)
4 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments
Bug 14843: Notifications and messages via REST API (36.75 KB, patch)
2015-09-17 10:40 UTC, Lari Taskula
Details | Diff | Splinter Review
Bug 14843: Notifications and messages via REST API (36.63 KB, patch)
2015-09-18 09:46 UTC, Lari Taskula
Details | Diff | Splinter Review
Bug 14843: Notifications and messages via REST API (35.77 KB, patch)
2015-09-18 10:08 UTC, Lari Taskula
Details | Diff | Splinter Review
Bug 14843: Notifications and messages via REST API (35.77 KB, patch)
2015-09-21 11:47 UTC, Lari Taskula
Details | Diff | Splinter Review
Bug 14843: REST API for message queue - /api/v1/notices (41.00 KB, patch)
2017-04-27 16:12 UTC, Lari Taskula
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Lari Taskula 2015-09-17 09:52:34 UTC
Add basic REST API operations for Notices. This way we can easily allow staff with correct permissions to resend/create manually new notices via REST API and accept third party delivery notes.
Comment 1 Lari Taskula 2015-09-17 10:40:05 UTC Comment hidden (obsolete)
Comment 2 Lari Taskula 2015-09-18 09:46:12 UTC Comment hidden (obsolete)
Comment 3 Lari Taskula 2015-09-18 10:08:30 UTC Comment hidden (obsolete)
Comment 4 Lari Taskula 2015-09-21 11:47:14 UTC
Created attachment 42719 [details] [review]
Bug 14843: Notifications and messages via REST API
Comment 5 I'm just a bot 2016-03-06 21:41:40 UTC
fatal: sha1 information is lacking or useless (Koha/AuthUtils.pm).
error: could not build fake ancestor at ./getter.pl line 196.
Comment 6 I'm just a bot 2016-03-06 21:41:56 UTC
This bug depends on bug7174 which is in status Needs Signoff but the patches for it do not apply cleanly
Comment 7 I'm just a bot 2016-03-06 21:42:28 UTC
This bug depends on 14723 which is in status Patch doesn't apply
Comment 8 Lari Taskula 2017-04-27 16:12:18 UTC
Created attachment 62791 [details] [review]
Bug 14843: REST API for message queue - /api/v1/notices

GET    /api/v1/notices
POST   /api/v1/notices
GET    /api/v1/notices/{message_id}
PUT    /api/v1/notices/{message_id}
PATCH  /api/v1/notices/{message_id}
DELETE /api/v1/notices/{message_id}
POST   /api/v1/notices/{message_id}/resend

New permissions:
- Module
  * messages
- Sub-permissions
  * get_message
  * create_message
  * update_message
  * delete_message
  * resend_message

To test:
1. prove t/db_dependent/api/v1/notices.t
Comment 9 Lari Taskula 2017-04-27 16:25:38 UTC
Still BLOCKED by Bug 7174 but I wanted to attach this heavily rewritten patch if anyone is interested to work with it. It is now dependent on Bug 18137.

This patch can work without dependency to Bug 7174, but at least the following steps are required:
1. The atomicupdate script needs to be rewritten to community standards. Get rid of AtomicUpdater and PermissionManager, and those permissions have to be added the way it currently happens in Koha
2. Fix permission adding mechanism in the test file
3. There are probably some conflicts in definitions.json, paths.json and parameters.json, but they should be trivial to fix.

I may return later to fix those steps, but if you really want to test this now, feel free to provide a follow-up :)
Comment 10 Fridolin Somers 2020-11-10 10:54:02 UTC
Needs to be added to
https://wiki.koha-community.org/wiki/REST_api_RFCs

In my opinion we could use :
GET    /api/v1/messages
Since we have message_transport, message_queue, ...

Note that table 'messages' is something else why may have to rename.