Ticket #11003 (closed PLIP: wontfix)

Opened 6 years ago

Last modified 6 years ago

Content governance metadata

Reported by: elvix Owned by: elvix
Priority: minor Milestone: 4.1
Component: User Experience and Interface Version:
Keywords: Cc: massimo, ggozad, plip-advisories@…

Description (last modified by elvix) (diff)

Proposer: Geir Bækholt
Seconder: Yiorgis Gozadinos

Motivation

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.

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

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.

Change History

comment:1 Changed 6 years ago by elvix

  • Owner changed from limi to elvix
  • Description modified (diff)
  • Milestone changed from 4.0 to 4.1

comment:2 Changed 6 years ago by massimo

  • Cc massimo added

comment:3 Changed 6 years ago by ldr

Presumably this requires another index in the catalogue?

comment:4 Changed 6 years ago by elvix

Yes.

(Technically one might be able to reuse the Creator one as that one will be made largely redundant, but i think it makes more sense to keep the two separate)

comment:5 Changed 6 years ago by robgietema

The "Creator" fields is specified in the DC specification as: "An entity primarily responsible for making the resource." So it doesn't mean the initial creator of the document but indeed the person who is responsible for the content right now. So I don't see why we would need an other field (and catalogindex).

Are you proposing to add another expiry date field which is the same as the current one but adding time delta's? Can't this be fixed with a widget only? Since "3 months from now" will be a fixed date also.

comment:6 Changed 6 years ago by elvix

We were planning to use the existing expiry date field.

Using the existing creator field, just exposing it for delegation might work as well.

comment:7 Changed 6 years ago by robgietema

Changed my vote to 0, +1 on using the existing expiry field and -1 to adding the responsable user field.

comment:8 Changed 6 years ago by elvix

  • Cc ggozad added

comment:9 Changed 6 years ago by elvix

I have no fundamental problem with reusing DC:Creator if it is actually a field and not just an old style CMF property on the object somewhere. And if it is, we'll be happy to override it. There is no particular need for more indexes here, just better behavior.

comment:10 Changed 6 years ago by robgietema

In that case I'll change my vote to +1 :)

comment:11 Changed 6 years ago by maurits

At Zest Software we have implemented something like this for a client. I need to have a look at this during the next month for some cleanup and using it on both their website and intranet. So I could at least mail you the package to get some ideas for how things could be done. Actually, I see it is split into two packages. I'll share some notes here about how we implemented this:

  • Uses archetypes.schemaextender for some extra fields; only a few content types use the registered adapter (e.g. it is not that interesting for a Folder).
  • Extra fields author_name and author_email to say who is responsible. Specifying just a user id is probably better, though you would indeed need a different widget for that. At least the fields we have here use the name and email address of the current user as default.
  • Field update_frequency: the frequency with which this object should be checked for validity (in days, default 180).
  • Not done yet: add a permission for allowing to set the update_frequency field; currently any owner can do that, but for one of the sites they only want the Manager to be able to do this.
  • After creating or editing an object, we use a small event handler to set the due date (annotation on the object) to the modification date (today) plus the update_frequency.
  • When viewing an item you see in the byline "Last checked by Johnny on 2010-09-15".
  • When viewing an outdated object (at least as Editor I think) you see a warning that the object needs to be checked for validity. A button is displayed to validate the page, which simply reset the due date annotation to today plus the update frequency.
  • There is a browser page that you can call in a daily cronjob to notify authors of possibly outdated info. An extra reminder date is set (annotation) after which date a new reminder will be set if the responsible author still has not revalidated the page. For some reason we have a funky small storage file in which we store a single pickle: the date the cronjob has last successfully run; we seem to want to avoid some theoretical zodb bloat here and it might help to avoid double emails. It seems failsafe enough, but I am somehow glad that I did not write this (small) part.
  • Catalog indexes and metadata columns are added for the author name and email, and the due date and reminder date; I'm not convinced that is actually needed for what we currently do with it. Ah, the dates are obviously needed in the cron job to search for outdated pages.

comment:12 Changed 6 years ago by cah190

  • Cc plip-advisories@… added

comment:13 Changed 6 years ago by esteele

  • Status changed from new to closed
  • Resolution set to wontfix

This PLIP has been declined for consideration for Plone 4.1.

Framework Team voting on this PLIP was:

Alec -1 Craig -1 Elizabeth -1 Laurence -1 Martijn +1 Matthew -1 Rob +1 Ross -

The Framework Team felt that this was not a common enough need to implement it as a part of the Plone core. They were also uncomfortable with the idea of repurposing existing metadata fields in a minor release. They've asked that you develop this as an add-on.

Note: See TracTickets for help on using tickets.