[Koha-bugs] [Bug 22615] Add /ill_backends endpoint

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Thu Apr 4 11:31:16 CEST 2019


https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22615

--- Comment #6 from Josef Moravec <josef.moravec at gmail.com> ---
(In reply to Andrew Isherwood from comment #5)
> I think the structure currently returned in /illrequests?embed=capabilities
> (which is just a JSON representation of what is returned from
> $backend->capabilities) is fairly logical:
> 
> {
> 	"CANCREQ": {
> 		"id": "CANCREQ",
> 		"method": 0,
> 		"name": "Cancellation requested",
> 		"next_actions": ["KILL", "REQ", "MIG"],
> 		"prev_actions": ["NEW"],
> 		"ui_method_icon": 0,
> 		"ui_method_name": 0
> 	},
> 	"COMP": {
> 		"id": "COMP",
> 		"method": "mark_completed",
> 		"name": "Completed",
> 		"next_actions": [],
> 		"prev_actions": ["REQ"],
> 		"ui_method_icon": "fa-check",
> 		"ui_method_name": "Mark completed"
> 	},
> 	"EDITITEM": {
> 		"id": "EDITITEM",
> 		"method": "edititem",
> 		"name": "Edited item metadata",
> 		"next_actions": [],
> 		"prev_actions": ["NEW"],
> 		"ui_method_icon": "fa-edit",
> 		"ui_method_name": "Edit item metadata"
> 	},
> 	"GENREQ": {
> 		"id": "GENREQ",
> 		"method": "generic_confirm",
> 		"name": "Requested from partners",
> 		"next_actions": ["COMP", "MIG"],
> 		"prev_actions": ["NEW", "REQREV", "MIG"],
> 		"ui_method_icon": "fa-send-o",
> 		"ui_method_name": "Place request with partners"
> 	},
> 	"KILL": {
> 		"id": "KILL",
> 		"method": "delete",
> 		"name": 0,
> 		"next_actions": [],
> 		"prev_actions": ["QUEUED", "REQREV", "NEW", "CANCREQ", "MIG"],
> 		"ui_method_icon": "fa-trash",
> 		"ui_method_name": "Delete request"
> 	},
> 	"MIG": {
> 		"id": "MIG",
> 		"method": "migrate",
> 		"name": "Switched provider",
> 		"next_actions": ["REQ", "GENREQ", "KILL", "MIG"],
> 		"prev_actions": ["NEW", "REQ", "GENREQ", "REQREV", "QUEUED", "CANCREQ",
> "MIG"],
> 		"ui_method_icon": "fa-search",
> 		"ui_method_name": "Switch provider"
> 	},
> 	"NEW": {
> 		"id": "NEW",
> 		"method": "create",
> 		"name": "New request",
> 		"next_actions": ["REQ", "GENREQ", "KILL", "MIG", "EDITITEM"],
> 		"prev_actions": [],
> 		"ui_method_icon": "fa-plus",
> 		"ui_method_name": "New request"
> 	},
> 	"QUEUED": {
> 		"id": "QUEUED",
> 		"method": 0,
> 		"name": "Queued request",
> 		"next_actions": ["REQ", "KILL", "MIG"],
> 		"prev_actions": [],
> 		"ui_method_icon": 0,
> 		"ui_method_name": 0
> 	},
> 	"REQ": {
> 		"id": "REQ",
> 		"method": "confirm",
> 		"name": "Requested",
> 		"next_actions": ["REQREV", "COMP", "MIG"],
> 		"prev_actions": ["NEW", "REQREV", "QUEUED", "CANCREQ", "MIG"],
> 		"ui_method_icon": "fa-check",
> 		"ui_method_name": "Confirm request"
> 	},
> 	"REQREV": {
> 		"id": "REQREV",
> 		"method": "cancel",
> 		"name": "Request reverted",
> 		"next_actions": ["REQ", "GENREQ", "KILL", "MIG"],
> 		"prev_actions": ["REQ"],
> 		"ui_method_icon": "fa-times",
> 		"ui_method_name": "Revert Request"
> 	}
> }
> 
> 
> So maybe a JSON object, keyed on backend name (e.g. BLDSS, FreeForm), with
> the the object being the above object? So:
> 
> {
>     "BLDSS": {
>         "CANCREQ": {
> 	    "id": "CANCREQ",
> 	    "method": 0,
> 	    "name": "Cancellation requested",
> 	    "next_actions": ["KILL", "REQ", "MIG"],
> 	    "prev_actions": ["NEW"],
> 	    "ui_method_icon": 0,
> 	    "ui_method_name": 0
> 	},
>         [..etc..]
>     },
>     "FreeForm": {
>         [...etc...]
>     }
> }
> 
> Having an object keyed on name, rather than an array would slightly simplify
> lookup.

I used array, because of consistancy with other endpoints - we always return
array on search, otherwise, I think we could stick with raw capabilites, as it
is

> In addition to getting all backends, I'm guessing it would be useful to have
> a search endpoint, such as /ill_backends?backend=FreeForm , which would just
> return a single backend.

Yes, that could be useful.


> Hope this is helpful?!


It is! ;)

-- 
You are receiving this mail because:
You are watching all bug changes.


More information about the Koha-bugs mailing list