Custom Query (2152 matches)
Results (1378 - 1380 of 2152)
|
Ticket
|
Resolution
|
Summary
|
Owner
|
Reporter
|
| #43 |
fixed
|
Generic Attributes for Packages
|
rgrp
|
rgrp
|
|
Reported by rgrp,
6 years ago.
|
| Description |
As A
User
I Want To
Add arbitrary named attributes to packages (an attribute being a name, type, value triple).
Details
- We will do this using a dedicated (versioned) table associated to Package
- Do we allow multiple attributes of the same name?
- For the present: No (since we will key by attribute name)
- Could allow for single attribute but with multiple values using json list ...
- What types do we allow or do we just rely on JSON to take care of this?
Questions (Original)
- How complex is this to implement?
- What would an arbitrary user be able to edit? Possibilities:
- 'create new attribute' and setting the value (so name and type would be chosen from predefined list).
- 'create', setting of name and value (but not type -- type already set in predefined list)
- Could just use (machine) tags -- though this could be seen as a bit of a hack.
- Would solve having to create special file/url attributes (though I think that perhaps file stuff is important enough to merit first class support in the domain model -- though, that said, since one won't want to have a file limit adding unlimited file support is very similar to unlimited attributes of arbitrary type).
|
| #44 |
fixed
|
Provide RSS/Atom Feed of Repository History
|
johnbywater
|
rgrp
|
|
Reported by rgrp,
6 years ago.
|
| Description |
As A
Visitor
I Want To
Get an RSS/Atom Feed of the Repository History to use in my feed reader (or elsewhere).
Details
- Preference for Atom.
- should just add parameter to /revision/list/ (or /revision/) to select atom format e.g. ?format=atom.
- should have a 'days' attribute specifying number of days back to go e.g. &days=30
Cost
Low
|
| #49 |
invalid
|
Filter Spam in Changes to CKAN Data
|
rgrp
|
rgrp
|
|
Reported by rgrp,
6 years ago.
|
| Description |
As A
sysadmin
I Want To
Have revisions to the CKAN data filtered in order to reduce the spam in the system.
Details
In the long run this is a quite a generic problem common across several OKF systems and probably can become a general component in the okfmisc repo. For time being focus on a well-factored CKAN-specific solution.
Suggest we follow path of trac: http://trac.edgewall.org/wiki/SpamFilter
Could have a general engine that aggregates spam scores from many different 'plugins' and then marks spam appropriately (actions should be configurable depending on spam level from 'purge' to 'delete' (mark revision as inactive) to 'flag' to 'do nothing').
Main initial plugins would be:
- regex filter (this would seem very useful here, e.g. do not allow urls in commit messages ...)
- could augment using the badcontent list approach (can find list on e.g. moinmoin)
- spambayes and/or akismet
|
Note: See
TracQuery
for help on using queries.