{22} Trac tickets (2647 matches)

• copy exisiting tests, modify authz in setUp, adapt and extend tests
  • Problem: default_role_actions is read by init_db
  • Solution: nuke db after monkey-patching
  • role = model.Role('Reader'), del role.actions[...]

self.PRE_MAUTHZ_RULES = copy(mauthz.default_role_actions) mauthz.default_role_actions.remove((Role.READER, Action.CREATE)) #raise Exception(mauthz.default_role_actions) model.Session.remove() model.repo.rebuild_db()

3. Start from the functional
   • Both the api controllers and wui controllers to do
   • tests/function/test_authz.py extended to check CREATE in lockedDown mode. fails nicely. ​http://bitbucket.org/pudo/ckan-authz2

is_authorized(user, Action.Create, model.Package)

-> Doing this will put 'Package' in the context field of the user_object_role table. This will trigger SQLAlchemy to attempt a join towards PackageRole? in all queries. Since for class-level role assignments there never is a PackageRole? join table entry, this will never return any results.

• cf branch "classes": ​http://bitbucket.org/pudo/ckan-authz2/src/6fd0475e0c66
• No possibility of including "instance" column in inheritance decision.
• Even if this can be cirumvented, it must happen on a per-query level and would require a major re-modelling.

• have a ckan install that would not allow visitors to either list packages or list groups
  • two paths: create the listing, but for each group/pkg decide that you cannot show this
  • lock down the whole page (/package/list)
    • this is class-based, not object-based

is_authorized(user, Action.Package_Create, model.System()) is_authorized(user, Action.Group_Create, model.System())

[Separating Package and Group roles may be useful going forward: PackageEditor?, GroupEditor? etc]

4. Find a standard way to lock down classes
   • possibly add default rows in user_object_role
   • introduce lock-down into controllers: group new, package new, REST equivalents,
   • confirm tests

• Copy & adapt Group controller tests to suit AuthorizationGroups?
• Copy & adapt Group controllers and templates for Authorization Groups

Much more natural place to do this, even at the risk of overloading the package edit form.

From Rufus:

'blackbox' testing command (read-only only would be fine) -- very
useful for upgrade on sunday

On blackbox thinking of something like:

paster test-site http://hmg.ckan.net {package-name}

Or (maybe better):

paster test-site --site-spec {myconfig.json}

my-config is a json file with info for testing (could overload
--config rather than site-spec):

site-url: http://hmg.ckan.net/
package-name:
package-title:
...etc ...

Then:

Test front-page
Test /revision/
Test /package/{page}  -- check title
Test /package/history
Test /api/rest/package/ ...
Test /api/search/package ...
etc

Looking at: ​http://ckan.net/package/rkb-explorer-acm

'rkb-explorer-resex' gets display multiple times and shouldn't

This has been done in IATI ckan but should be ported over to CKAN main and put into the UI in a nice fashion.

IATI: ​http://bitbucket.org/okfn/iati/changeset/378431974c76 (related to #520)

Requires SOLR search backend (for postgres should fall back gracefully -- just do not show them).

• Uses API to change licenses of all packages in a CKAN instance to a particular one.

• Run it on DGU.

• Add help text, drawing from:
  • ca.ckan.net
  • ​http://wiki.okfn.org/ckan/doc/package
  • ​http://wiki.okfn.org/ckan/doc/faq
• Make longer text revealed on click

​https://trac.dataco.coi.gov.uk/projects/datagov/ticket/613

Database for all CKAN instances upgraded to Postgres 8.4, but none of the eu machines were upgraded with the tools necessary to administer them.

This proposal is to discuss adding a new API for proxying certain spreadsheet data via JSON-P to make it possible to build simple browser apps directly off the API.

See the attached proposal for information.

Editing groups in forms doesn't work for me, with latest code from this morning:

1. Clean db
2. paster create-test-data
3. paster sysadmin create ​http://davidread.myopenid.com/
4. paster serve development.ini
5. In browser, log in to CKAN
6. Create new package: name=abc group=Roger's books
7. [Preview] - yes group appears
8. [Save] - shows package and group hasn't appeared ERROR
9. Check ​http://127.0.0.1:5000/api/rest/package/abc and reedit package it also doesn't appear here either.

Previously, a package type attribute was intended to distinguish between package data that came from government depts. and publishers location information (GEMINI). Now there is an intention use a common set of attributes to support data from either source.

Hence, there currently a v.3 of the government attributes, a document about extracting the attributes from Gemini document using XPath, and a comparison documents mapping between governemtn attributes and Gemini attributes.

That means there are potentially four different list of attributes. I'm not sure how to go about reviewing the lists and converging any differences.

But we do want to end up with a list of names, a description of their purpose, and then perhaps the XPath which would reveal the value from a Gemini doc?

So that Drupal doesn't need to make any adjustments to the form, and risk data being lost on submission.