Custom Query (2152 matches)
Results (532 - 534 of 2152)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#1270 | fixed | Default site www.ckan.net is a redirect and loses POSTs | dread | dread |
Description |
The default site was www.ckan.net, which had an Apache 301 redirect to ckan.net, but the problem was urllib was not rePOSTing stuff. This affected search parameters: In [1]: import ckanclient In [2]: c = ckanclient.CkanClient() In [3]: c2 = ckanclient.CkanClient('http://ckan.net/api') In [4]: c.package_search('', search_options={'groups':'openspending'}) Out[4]: {u'count': 2102, u'results': <generator object _result_generator at 0x10168b1e0>} In [5]: c2.package_search('', search_options={'groups':'openspending'}) Out[5]: {u'count': 29, u'results': <generator object _result_generator at 0x10168b410>} Thanks to borior for finding this and raising it. |
|||
#1283 | fixed | Deleted packages shouldn't be searchable or browsable | dread | dread |
Description |
A package in deleted state doesn't show to general users, but admins DO see them. The idea is that they can resurrect them if they want. But now we have the trash can that lists deleted packages. So we don't want admins to see the deleted packages anywhere else. (But an admin should still be able to READ and EDIT a deleted package, so if he clicks on it in the trash list he can see it to decide whether to resurrect and actually be able to change its state.) Same in the Web interface and API. This ticket ties in with #948 highlighting a package being deleted (when viewing or editing) and follows on from the introduction of the trash can #1076. |
|||
#1289 | wontfix | Remove 'relationships' | dread | |
Description |
AbstractPackage Relationships have not taken off in the 18 months we've had them in the API. There are some issues with them and we need to spend more time improving them or consider getting rid of them. The ProblemOriginal use cases are expressed here: #253 Here are comments about how we could handle these specific examples better:
3&5. derived resource - better to have some sort of resource relationship perhaps?
Outstanding issues needing serious effort to fix:
SpecificationRemove relationships from model, API, tests, Web UI. Data migration to remove from db. Why do it this wayGetting frustrated having problems with the code, when it's not used much. Often asked about what it's for, but rarely used. Seems an overly complicated design. Backwards Compatibilityn/a Implementation planDeliverablesSee Specification Risks and mitigationsRisk: a customer suddenly wants this, and the new ways to relate resources are not in place yet. Mitigation: discuss this decision thoroughly to make sure we are confident the use cases are not important. Discuss with team, ckan-discuss and specifically the LOD people who have some related packages on thedatahub.org. ParticipantsDavid Read ProgressNot yet. |