Custom Query (2152 matches)
Results (1840 - 1842 of 2152)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#323 | fixed | Notification message | dread | dread |
Description |
Which events to notify onListed by domain object, these are the notification message 'change types' that will be sent:
Also it is clear that it could be useful to know when db-wide maintenance is carried out:
Ignored domain objectsThese parts of the domain model will not carry notifications as no use case has been identified for them:
Message formatA notification message's header contains the routing key, identifying the object type. The client is probably interested in the object (all use cases so far), so it makes sense to send the object in the payload. This should be the JSON-encoded dictionary exactly as provided for the object's REST Entity. For the 'db' notifications there shall be no payload. |
|||
#322 | fixed | Client interface for Notification Service | dread | dread |
Description |
Use cases
Design
Routing detailRouting key format: "OBJ_TYPE" (NB tags should be identified by their name, not ID) Example routing keys
Example queue bindings that clients may use:
VersioningSince message payloads will be tied into the REST Entities, it makes sense to join up with the REST versioning. This could be achieved by providing new exchanges called 'ckan-1.1' perhaps? Documentation
|
|||
#321 | duplicate | Delegate authentication to Drupal | thejimmyg | johnbywater |
Description |
When CKAN is included in a Drupal front-end, CKAN edit pages are used in a slave-mode, such that authentication is delegated to the Drupal front-end user model. The Drupal front-end shall have:
indicates what has happened, and how to ask for permission. The CKAN slave edit page shall:
|