Ticket #11004 (closed PLIP: duplicate)
Content governance metadata
Reported by: | elvix | Owned by: | elvix |
---|---|---|---|
Priority: | minor | Milestone: | 4.0 |
Component: | User Experience and Interface | Version: | |
Keywords: | Cc: |
Description
Proposer: Geir Bækholt
Seconder: Yiorgis Gozadinos
Motivation
Plone lacks some basic metadata features. Our metadata receives little attention and is mostly the same as when Plone 1 was written, a direct use of CMFmetadata, based on Dublin Core and not on what a CMS in real life use needs. We need improved metadata so Plone can assist the editors in keeping their content up to date (a process called “content governance” by the buzzword-ers and corporate information people). The proposal is to be able, for every piece of content, to know who is responsible for keeping it up to date, when it becomes out of date, as well as to ensure the responsible person is appropriately informed about the need to update the content.
Assumptions
It is hard to manage a lot of content over time. Most people that run a Plone-based intranet end up with an unmaintainable mess after a few years.
Proposal & Implementation
We need a field, namely “Responsible person”, defining which user is responsible for keeping the content up to date. While there exist some related fields, i.e. "creator" which is not sufficient as it refers only to the orinal cretor, and the "owner" role which relates to workflow permissions, these are not sufficient to cover the use case. In addition, we propose that the “expiry date” field which already exists (but is typically used wrongly if at all) is used to mark the date upon which the content will be marked as out-of-date. Responsible user field: Should default to the creator of the content, but can be set to somebody else on a per-item-basis. User selection Widget: It is possible to start with a string widget and ask the user to provide the username of the responsible person. Eventually though we should have a user selection widget that could be vocabulary based for sites with few users or a search-based widget for sites with a large number of users. Expiry date field: The expiry date field could be a selection field where the default would be the current expiry date, followed by options that would default to reasonable time deltas, for instance “3 months from now”, “1 year from now”. Last should come the option that the item “never expires”. By selecting one of the options the date will be set on the field. It should also be possible to set a specific date in the future manually. Updates to author page: The author page should list what content the author is responsible for, not the content he has created. Update to byline and content listing templates: There are several locations in Plone where we list the name of the creator of the content along with the content title. This should be updated to list the responsible person, not the creator. Update to the content view: An additional viewlet can be created that will appear on content that has expired. It will mark the content as expired as well as provide a link to contact the responsible person. Portlets: A portlet to show content that the user is reponsible for. A portlet to show content that the user is reponsible for and is about to expire or has expired already. Both would be registered for the dashboard.
Deliverables
- An extra field, "responsible person", added to the base metadata schema.
- Portlets showing content the user is responsible for, as well as portlets showing content expired or about to expire.
- Migrations
- unit tests
- Localization
- Optional: A widget to pick a user.
- Optional: a portlet showing the person responsible for the current content (very useful on intranets)
Risks
No major risks. If there is no good widget for selecting users, there will be extra work involved in making one.
Participants
Who is signed up to do the work? Geir Bækholt (elvix), Yiorgis Gozadinos (ggozad)
Progress
Created the field in an add-on product in the collective (collective.contentgovernance), but ended up realizing that implementing this as an add-on is more pain than it is worth, and most of the gain from extra metadata is when it is default so everyone can depend on it.