Custom Query (2152 matches)

Reported by rgrp, 4 years ago.

As a sysadmin I want to configure basic site title information for use in the site templates.

Implementation:

• ckan.site_title config variable
• set this on g in app_globals.py e.g.
  • from pylons import config; g.site_title = config.get('ckan.site_title, 'CKAN - Comprehensive Knowledge Archive Network')
• use in head title and in main site title/logo section (use it as alt on logo image)
• Also all other pages (e.g. index, about) which talk about CKAN
  • Is this needed? Would it not be better for people who want to customize the site to simply overwrite those templates?

Questions:

• Do we want a site_logo variable whic his use for site title/logo section instead of site_title if site_logo defined?
• Probably yes, but not part of this ticket.

Reported by johnbywater, 4 years ago.

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:

1. Login page - fixed location, can authenticate users, on successful authentication sets auth cookie and redirects to HTTP_REFERER.

2. Access control resource - fixed location, can authorise users, on receipt of valid auth cookie return message listing account details and permitted actions.

3. Access denied page - fixed location, static resource, gently

indicates what has happened, and how to ask for permission.

The CKAN slave edit page shall:

1. Try to detect a Drupal session key (passed as cookie or as request param).

2. Redirect to Drupal login page if no session key.

3. Check authorisation if session key is found.

4. Redirect to access denied page if session key not authorised.

5. Present the Package edit page.

6. Reject unauthenticated or unauthorised edit submissions.

7. Snag invalid edit submissions from authenticated and authorised users.

8. Respond to valid edit submissions from authenticated and authorised users, by saving the new package state, and redirecting to Package read page in Drupal front-end.

Reported by dread, 4 years ago.

Use cases

• Register for package changes
• Register for all revisions
• Notified of a package change
• Notified of a revision
• Deregistration
• Configuration of port in pylons config

Design

• Default port: 5672 (standard for AMQP)
• Exchange name: 'ckan'
• Exchange type: topic exchange (most flexible)
• Routing keys: (see below)

Routing detail

Routing key format: "OBJ_TYPE" (NB tags should be identified by their name, not ID)

Example routing keys

• 'package' - Package edited/created
• 'resource' - Resource edited/created
• 'revision' - Any change
• 'db.clean'
• 'db.rebuild'

Example queue bindings that clients may use:

• * - no filtering - client receives all notifications
• package - only changes to packages
• revision - all revisions
• db - all database operations

Versioning

Since 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

• How to use
• simple example of an external client?