{22} Trac tickets (2647 matches)

For example here: ​http://s031.okserver.org:2375/en/dataset/new_resource/gold-prices The breadcrumb shows "gold-prices" which is not the title of the dataset

Currently lower case 'active' is the name of this page: ​http://s031.okserver.org:2375/user

Should be 'All Users' or 'Active Users'

navigating to a user page -one's own or ​http://s031.okserver.org:2375/en/user/ira or ​http://s031.okserver.org:2375/en/user/shevski, even when signed out is noticeably slower than navigating between other parts of the site; over 2 seconds. Maybe even 3

The new ckan creates datasets as part of a 3 phase process. To allow for this partially created datasets can have a state that is 'draft' or 'draft-complete'. These datasets should not be seen as active by the activity stream.

If we click 'add dataset' and then complete the first phase of adding a dataset then we end up having a activity stream created. When we add a resource in the next phase (add data) again an activity stream item xxx added resource to dataset is created

We do not want these adding. Essentially if a dataset has a state.startswith('draft') then we want the activity stream to ignore all actions involving it.

finally when the state is changed form state.startswith('draft') to state=='active' we want a xxx has created dataset ... to be added to the stream.

The best way to do this would be to branch from 2375-demo-theme-stable and get it to work there.

Let me know if you need any help with this ticket or a better explanation of the problem.

Can we add the related dashboard (​http://trac.ckan.org/ticket/2347) to demo - central place to show off all the related stuff added.

Currently, as a logged in admin, you can view deleted datasets just as if they are live datasets. Nothing distinguishes them apart from normal datasets other than they don't show up on the dataset page

This is potentially very confusing Can we add some kind of banner / label to deleted datasets to show they have been deleted?

& Do you guys need Sam to design this?

Related ticket for undeleting datasets - ​http://trac.ckan.org/ticket/2780

demo.ckan.org has a small field for adding text on homepage current text: "Welcome to the CKAN demo Try out standard CKAN functionality in a sandbox environment. Search for datasets directly from the homepage or by navigating to the Datasets search page where you can facet by tags, groups and format."

Want to make this editable for demos

Really we want this for CKAN Hosted & for creating demos.

Currently we're using ​http://leaflet.cloudmade.com/ - but by finding the area & taking screenshots. Would be better to interate with the app so that: a) this happens automatically and b) correct attribution will be visible on maps

be good to do this in phase 3

on resource pages (e.g. ​http://s031.okserver.org:2375/dataset/afghanistan-election-data/resource/f6331f99-51f6-44d9-95b9-b20f3b74f360), same as old ckan for continuity and to highlight!

reported as editing datasets incorrect

e.g. clicking on edit here ​http://s031.okserver.org:2375/dataset/ff takes you to create dataset page ​http://s031.okserver.org:2375/dataset/edit/ff

but this is the correct behaviour of a draft dataset

We need to show draft datasets correctly

proper tickets need making for the different issues after review of issues with them - who can see, where, admins and viewing, orgs too etc

On harvest page: ​http://s031.okserver.org:2375/harvest the checkbox appears above the text and not clear what it refers to/

Beter to relocate to the left (as on publicdata.eu) see screenshots attached.

should be left alighned, not right aligned. Otherwise tag line disappears left off the page.

See: header here: ​http://s031.okserver.org:2375/ckan-admin/config

Tried to refresh the datagm harvest source to get error message:

"An error occurred: [There already is an unrun job for this source]"

This is unclear and not sure why it created an error. We should have something informative such as "A harvest has already been scheduled for this source"

Do we have a date/time for when this has been scheduled that we can display?

e.g. tried changing the lang here: ​http://s031.okserver.org:2375/ to no effect. Doesn't work on any other pages either. Flags have also dissappeared

e.g. second option in left hand sidebar is follow another user' ​http://s031.okserver.org:2375/user/dashboard but if you click on that and then any user, there's no follow button

to me the dashboard user stuff is highly unfinished and probably should not be included unless someone is very keen for it

can we add in the breadcrumb navigation to qa pages so that you can go back to ​http://s031.okserver.org:2375/qa from sub pages such as ​http://s031.okserver.org:2375/qa/dataset/five_stars

e.g. I can see 'You haven't created any datasets. Create one now?. ' ​http://s031.okserver.org:2375/user/kindly when logged in as shevski

tested with my ​http://s031.okserver.org:2375/user/shevski and daniel's account. I have added about text and yet see ' Irina Bolychevsky

You have not provided a biography.'

The about text is saved (and viewable on the edit form itself) but does not show on profile

The JavaScript? email encryption used is not very reassuring. Google's MailHide? is a much better solution that is easily implemented.

​http://www.google.com/recaptcha/mailhide/

Check on the Mailhide API where there are even some Python libraries already built.

Auth Proposal

Use case: We'd like an authenticated and authorized Drupal user to be able to edit/delete packages using the API

To do this a user would need a CKAN API key so we need some way of Drupal telling CKAN who a user is so that they can get their API key.

Proposed Implementation

A user visits the CKAN API key page to get their key. Because CKAN is at catalogue.data.gov.uk (a subdomain of the Drupal site) it can read Drupal cookies.

If there is no DRXtrArgs or DRXtrArgs2 cookie, we know the user isn't signed in so we redirect them to Drupal to sign in.

WISHLIST: It would be really nice if we could pass the URL to redirect back to Drupal so tha Druapl can send them back to the CKAN API key page

Either way, they get back to CKAN and now the cookies exist. When the first HTTP request header is sent, CKAN will read the Drupal session ID and then call a Drupal API, server to server.

TODO: Implement an API on the drupal server which accepts a Drupal session ID as an argument and returns the username and credentials, but only if the request if from the CKAN server (perhaps we specify an API key in the request)

If the session is valid CKAN will set its own auth cookie and show them the page with the API key. CKAN only considers a user signed in if both the CKAN cookie *and* Drupal session ID are present. If at any time they sign out of Drupal the Drupal session disappears so they will be signed out of CKAN too.

Now the user has an API key they can use the standard CKAN command line API tools.

The API key is the only thing the user will need to use the CKAN API. This poses a problem. What if a user is removed from Drupal but still has a CKAN API key?

Two solutions:

1. API keys will be set to only be valid for the length of a Drupal session so that a user will only be able to use the write API for a little time after credentials are revoked

2. CKAN provides an API to allow Drupal to revoke keys

Option 1. seems easier to me. If we choose this we will write a get_api_key command line tool so that Drupal user can write things like this:

::

datapkg list_packages --api_key get_api_key

The get_api_key function will prompt for username and password and then perform the steps necessary to get an API key.

Based on the ideas in:

• DistributingChanges
• SyncingInstances

Merging the tickets #296, #297, #298, #299 into this one.

Related ideas include:

• Using dcat to exchange data
• Using couchDB to have a stub package record synchronised between multiple CKAN instances, each linking to the main record in the correct instance

This should be considered a wishlist item for the timebeing.

Should have the following features:

• A list of all packages with broken links on the resource
• Under each packages a description of any resources with broken links to include:
  • Link
  • Description
  • Format
  • First found to be broken date

[If you can't do the last one yet, don't worry]

For example, I will document the following:

• A specific guide on using mercurial when working with our branching and merging policy
  • DONE - ​http://wiki.ckan.net/Becoming_a_CKAN_Developer
• Policy document on how we use tickets, plan sprints and make releases
  • DONE - ​http://wiki.ckan.net/Becoming_a_CKAN_Developer
• How to package software as .deb file for project deployment

I'd love if someone else would write:

• An authorisation tutorial covering the core model, the command line tools and examples of every possible way of using the system
• A HOWTO guide with screenshots for adding a package

Here are some proposed changes related to CKAN's authorization system - they aren't very big, but should provide for some forthcoming use cases including #787.

Two man reasons for the changes are:

• We have a completely refactored architecture now which introduces a logic layer. These Auth changes are designed to better support the way we work with that layer.

• Different CKAN extension apps may need radically different authentication/authorisation so we need to allow whatever we have to be override-able.

The first two changes revolve around the is_authorized method, which is called by the logic layer to ask whether a particular user (e.g. Bob) is allowed to do a certain action (e.g. edit) on a certain object (e.g. Package).

1. The first thing the is_authorized method is a hook to a plugin

which *overrides* the current call with its own implementation (note: in previous discussions we have considered allowing a chain of plugins, no longer!)

Reason: authorization can be completely delegated to another system (or partially)

2. is_authorized method currently takes (username, action, object)

but for action=create_package, the object supplied is System, and for action=edit the object supplied is the package. Instead action should always be the string name of a function in the logic layer and object should always be the object passed to that function. This means our auth system is based around the actual actions we are performing (rather than a model them) and with the actual data that forms the action (rather than a related object). You never need a System object in this model.

3. Rename these two classes to better reflect what they are
   • AuthorizationGroup? -> UserGroup?
   • Group -> PackageGroup?

4. Rename the Editor role to PriveledgeUser? since Editors sometimes can't edit.

Although this sounds a bit radical we already have auth extensions.

Read-only CKAN Web UI

(Additional requirement from #764)

Whilse using CKAN web interface, you are not tempted to edit stuff:

• You know at all times this CKAN is read-only
• All editing facilities are still seen but greyed-out with an indication why it is.

Progress can be tracked in this document:

​https://spreadsheets.google.com/spreadsheet/ccc?key=0Atp3cZFjuIOAdFQzRnVoUHV6ckoyblI5TUdEcnJLVlE&hl=en_US#gid=0

Child tickets:

• #1194 "Welcome back" message for newly registered user
• #1202 Links to datapkg utility don't lead to info about it
• #925 Change the search box icon to remove the down arrow
• #923 Search box doesn't work in leaderboard page in stats extension
• #1034 Flash message cached
• #737 Markdown syntax summary page
• #811 Extra field editing form layout breaks when there are long field names

Child tickets:

• #234 UI Review - Autocomplete package names & tags in search
• #193 Searching by time-related field
• #191 Searching by modification date
• #905 Unable to search with accented characters in package names
• #906 Ability to search without accents for accented words
• #924 Search box has no search button

Broadly speaking though we need to choose PostgreSQL, Solr or something else. We don't want to invest our time maintaining two search backends with a limited abstraction layer between the two.

Perhaps the importer deletes them before re-importing. We shouldn't have deleted resources, so let's investigate.

The extension needs upgrading:

No module named webstore.database

The other option is to delay this functionality and merge with the publisher dashboards after the group refactor.

John, David Raznick, David Read, Ira, what do you think?

At the moment most of the harvesting functionality is only available to sysadmins. This is fine for most cases but going forward we will need to grant each publisher access to their own sources, harvest objects and harvest object errors. This will probably be done based on the groups refactor.

One more pressing concern is giving DGU publishers the ability to make calls to /harvest/object/id. We want them to be able to see documents that faild validation and also to see *all* errors in each document.

Pawel knows about this so David Read, Pawel and I need to find time to discuss it.

Now that we have a geospatial search API, we should build a front-end that integrates with the existing search for displaying results.

This would allow deployment via Nginx or Apache using proxy to Paster, uWSGI. At the moment CKAN isn't aware of the proxy's IP address so when you perform an action which does a redirect (such as adding a package), CKAN redirects you to the *internal IP* not the external *proxy IP*.

We would like this work to facilitate testing within VMs as part of our new build infrastructure.

It would also be nice if CKAN worked when mounted at a path other than /. That could be dealt with in another ticket because it isn't a problem at the moment.

The Handle System is an initiative to provide persistent references for resources. That is, it's basically a proxy system for preventing link rot.

Its documentation is here: ​http://www.handle.net/. Servers running CKAN could host a "Local Handle Service", which redirects a hash of a resource to an actual URL.

Some suggested use cases:

• Researcher would like to cite where data came from
• Agencies would like to have a way to prevent vendor lock-in from CKAN if they decide to move to another platform

Data viewer / previewer for a resource that has a KML file, or others, such as GeoRSS and GeoJSON, we should provide a map.

• Support for KML files: #1458

This is non-trivial for external files as we need a way to jsonify. For files stored locally this is more of a recline issue (and will require a bit of work to either guess columns or allow user to specify them).

When a package has been deleted, say for spam moderation, comments still appear in the recent comments section.

This is a problem because non-admin users will be shown a warning that they're not authorised to view the package if they click on the link.

At CKAN.net currently, this affects the most recent comment.

Administrators have "View", "Edit" and "History" tabs. However, I can't see a way to delete a package from the web UI.

Version: CKAN.net as of today

A new library, ​guiders.js, has been open sourced that seems to be great at unobtrusively introducing new users to features of websites.

The library drives Optimizely's website. The GitHub repo is here: ​https://github.com/jeff-optimizely/Guiders-JS

Some examples:

As reported on ​ckan-dev:

items in the footer of CKAN ("Packages", "Groups & Tags", "About", "Language", etc.) are shown vertically instead of horizontally in IE7. This works fine in later browsers like IE8, IE9, FF4, and latest Opera and Chrome.

This seems to exist in all recent CKAN versions up to 1.4.1a.

Produce a video explaining some of the things which can be done on the datahub.org

If someone who is not logged in clicks on "Upload Data", they are presented with

    Not authorized to upload files.

This is in emboldened red text. That is, the system is telling a user that they're doing something illegitimate, even though they're actually following an invitation from the main menu.

I propose two options for resolving this:

1. only display the "Upload Data" tab if someone is authorised to upload data
2. if someone isn't logged int, provide a nice welcome message thanking them for wanting to upload data, but we only allow registered users to do so

ENV: thedatahub.org, CKAN 1.4.2b

eg 404 page

create a 404 error via a bad url - translation links go to /document/error not the actual bad url

need to sort cookies etc

should work with nginx and varnish

• cache admins etc
• aim to move check_access so independent of logic function
• general spruce up

TD look at issues and then email ckan-dev

meeting notes from 21-3-2012 general ideas non specific

Problem:

• We want to remove the Transformer usage due to performance and its close tie to genshi
• Want a standard way for core code and extensions to put code into the templates where *templates request it* (templates control insertion rather than extensions ...)
• Stacking versus overwriting on entry points
  • Relationship to h.requires('jquery', version) - ​http://codex.wordpress.org/Function_Reference/wp_enqueue_script

Options:

• placeholders or helper methods
• {{user _info}} {{sub_menu}} is this equivalent to <span class="insert-user-info"></span>
  • [xyz arguments] -> h.load_snippet('xyz', ...)
• ${h.snipit()}

look at reducing what is pulled into templates eg ckan.lib.helpers ensure that these changes don't break existing extensions etc

get working on TDH

look at removing stream filters

• Do an analysis of why upgrades are problematic
• What can we do better
• Decide what to implement