{22} Trac tickets (2647 matches)

Create plugin system using <​http://pypi.python.org/pypi/pyutilib.component.core/>

Specification in CEP-003 (browser:doc/cep/cep-003.txt) and <​http://okfnpad.org/ckan-plugins>

...obviously, not all packages will have a harvested metadata document.

I suggest we produce a quick Markdown cheat-sheet page, showing the key runes: e.g. create a title and quote some text. This page can link to the full Markdown docs for advanced users.

A user going to the Markdown docs that we link will have to read a couple of pages of the raison-d'etre of Markdown before he gets to the syntax. And it's not very easy to read, and being white on black it looks like proper geek stuff.

ww 22/9/10:

(discussion of ticket:509) This leads us to deduping which should be the next order of business oin this thread...

ww 20/10/10:

if a dataset is missing a department and the ons script makes a new version of it with a department we now have two reccords for the same dataset. these should be manually merged - need a merge tool where you can tell it that two datasets are the same.

Sometimes editing a package via api on dgu results in some countries being lost in geo coverage.

Move from hetzner box to s3.

With a pending state set ("unapproved")

... probably by adapting aidtransparency.net

Symptom #1: Groups without titles don't get a clickable link, because there is no text. Defaulting to the group name would solve this trouble. Symptom #2: Package groups drop-down list show's 'None' when a group doesn't have a title.

Therefore, we need to centralize presentation of group title, so it defers to group name. And we need tests.

Also please sort groups by title on group list page.

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?

When getting a search results page (e.g. ​http://ckan.net/package/search?q=development&open_only=1&downloadable_only=1) and then using the on-page links to page through results, the next link / numbered page links go to ​http://ckan.net/package/search?q=development&page=2 rather than ​http://ckan.net/package/search?q=development&open_only=1&downloadable_only=1&page=2 meaning that the filter flags set (Download Only; Open Only) are not respected on the second page of listings.

This seems to require doing something else with such a group's 'delete' button, such as showing it greyed, or perhaps not showing it at all.

e.g. searching for 'buddhist' or 'sanskrit', you don't get this newly created package: ​http://ckan.net/package/digitalsanskritbuddhistcanon

... and make cache-control header optional

Done. Added release process here: wiki:ReleaseProcess

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

• 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

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

• Run it on DGU.

See message and script: ​http://lists.okfn.org/pipermail/ckan-discuss/2010-September/000569.html

1500 requests shouldn't take hours.

Discussion between John and Peter:

Given we can identify a document, does the disappearance of a document from a registered source imply the disappearance of the metadata (such that we delete packages once the documents disappear from the registered source)?

I would expect a more explicit 'delete'. The UKLP Use Case Library describes this as "withdraw a dataset or service from publication" (part of UCD03 Maintain resources).

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

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

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

Auto way to check web and API interface of a CKAN instance basically works. Several gotchas can be quickly determined, such as logging in, search not working. Needs to be configurable per site basis.

When people link to a package, a track-back link is auto-created. (Similar system as for blogs).

As suggested by Tim Davies:

Allowing some form of ‘track back’ against datasets When a non-technical user comes to look at a dataset it would be really useful for them to be able to see if anyone has created an interface interpretation of it already.

I found quite a few cases in research of end-users struggling to make sense of a dataset when good interfaces to that data had already been built and blogged about, but without there being any link from the dataset listing to those data uses. Accepting track backs could also make it easier for technical users to find blog posts / shared code etc. relating to a given dataset.

This needs to be abstracted and we still need to be able to remove items before saving.

Authorization Groups:

• Rename UserObjectRole? to SubjectObjectRole?
• Create database migration to do the rename in DB
• Make sure all the tests are passing again

(Doing this first seems more stable since we first want to "re-gain" exisiting functionality)

• Create authz.py and model tests for authorization_group-based auth
  • tests: functional: create fixtures, do actual requests

lib-tests: test for membership addition, removal, group-right additions affecting all members, group-right removal, group rights affecting non-members.

# * Adapt model to get these passing

• Integration into existing controllers should be negligible but may want ot have tests
  • do not want that. would mean design is broken
• Need to create a new controller for editing authz groups (will have same permissions as any other object -- Reader, Editor, Administrator)