Custom Query (2152 matches)
Results (1894 - 1896 of 2152)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#333 | wontfix | CKAN front end requirements for package notifications | dread | |
Description |
Use case: new package
The notification message (step 5) has to get through to the front-end that the new package is created before the redirect (step 6). This suggests that the message sending needs to be *synchronous*, i.e. acknowledged by the front-end, before CKAN redirects the user to the front-end package listing page (step 6). In addition, this use case suggests the front-end listens for package notifications, to save another call to CKAN to get the package details, before the displaying the list of packages. If this isn't possible (see next use case) and it must listen for revision notifications instead, then perhaps it is worth including the full package details in the payload for the revision notification message. Would there be a problem with such a large message in the next use case, with 100 packages? Use case: CKAN imports packages
The package addition could be achieved in 1 revision, 100 revisions or some compromise:
This use case suggests a bulk import of packages should go into one revision, and therefore generate one revision notification message and 100 package notification messages. The front-end client should listen to only revision messages. |
|||
#1467 | worksforme | CKAN dumps dgu miss certain publisher information | thejimmyg | thejimmyg |
Description |
Pawel knows about this so David Read, Pawel and I need to find time to discuss it. |
|||
#1551 | fixed | CKAN auth for webstore changes | ross | ross |
Description |
Webstore should use auth api ( #1550 ) for authenticating users accessing webstore rather than talking directly to the CKAN database. We also need it to suppose /user/ urls and /userid/ for accessing databases. |