Date Created, Date Modified and Author as System values on entries
This is an open discussion with 12 replies, filed under General.
Search
This has been discussed. Our thought is:
An optional system date element that one can include via the DS:
<system-date created="2009-07-16" created-time="13:16" updated="2009-07-16" updated-time="13:17" />
@author
is useful enough that we can bake that into the <entry>
element.
Nice and semantic.
How do you feel about the Author? Being able to filter a Data Source by “System Author” kind of removes the need for a separate “Author” field. Where do the boundaries lie? And do we have separate created-by
and updated-by
?
Love this idea. As for authors, I’d think it’d be important to still have a field. For example, sometimes a site admin will need to post something authored by another user, or sometimes you need to specify more than one author. But the field could have an option as to whether or not it’s displayed for that section…
In pure database terms that entry was still created by you though. For pure publishing terms you may want to use an Author field to make this editable. But for pure data auditing purposes you may want a system author reference that cannot be edited.
Yes, right. I was thinking on a different plane…
I’m all for it!
There would be a small problem for entries created via frontend events. Possibilities:
- being able to pass a
fields[system:author]
field with an ID - fall back to
NULL
if none sent, and gracefully degrade (i.e. not show the attribute) in the XML
Scanning through the database and it seems sym_entries
already does store the Author ID in an author_id
column. Sweet! So now it just needs to be made visible in the UI for filtering.
In response to Trevor’s requirement of an author seeing only their entries, I think this would actually be very simple to do. We’d need to add a checkbox to the Authors area along the lines of “Only show entries created by this author” (or perhaps even done by Section).
The database query that is used in the /publish/ pages to create the table list of entries would need to detect if this checkbox is ticked and factor the author_id
into the SELECT query too. Indeed it could also be checked when viewing an entry, in case an author decided to change IDs in the URL.
It would only be one step further to add full section-level permissions to the core; although I get the impression the team are reluctant to retro-fit this since they’d rather focus on Symphony 3.
That’s the impression I get. So it’s up to the community to lend a hand.
I don’t want to begin a fully-featured UAC if this is coming in Symphony 3. But I do think that some light user control might be appropriate. Since Symphony does store the author_id
against each entry created, and I’m not sure where it ever uses this information, this is perfect for a most basic “Show only entries created by this author”.
In a multi-user environment this might be useful (as in Trevor’s requirement). But come to think of it, I’ve yet to come across this requirement myself. Usually in a multi-user environment there is trust over the content management. If the requirement from Trevor is that he wants to give a community of bloggers an author account each to allow them to create blog posts, there will also be the problem of authors being able to see all sections and not just the ‘Blog Posts’ section.
I like the idea of optionally making some extra information available through data sources and output parameters.
However, if you are in a multi-user environment it may become useful to track who is updating entries too. This is the case where authors may see other authors content and edit it. This kind of functionality is only a small step away from storing the history of each entry (e.g. entry, author, update-time). It should not be part of the core, but would be useful as an extension for certain sections.
rainerborene raised this today so this is worth discussing further.
I like Allen’s suggestion of an optional system-date
element in the XML. I also think that the System Date needs to be filterable through a Data Source, to negate the need to add a native Date field to every section that needs ‘timestamping’.
This kind of functionality is only a small step away from storing the history of each entry (e.g. entry, author, update-time). It should not be part of the core, but would be useful as an extension for certain sections.
I’m 75% through putting together a working prototype for entry versioning that supports created/updated dates and author references. I still think “System Date” should be in the core though — it’s a standard attribute of every entry in the CMS.
Create an account or sign in to comment.
A lot of the time I find myself adding a “Date Created” date field to most Sections with “pre-fill with today’s date” enabled. This instantly gives me a date when each entry is created. Symphony already stores this information which is presently only available as the “System Date” as an Output Parameter in Data Sources.
I propose the following:
sym_entries
to include in addition toSystem Date
, a “Last Modified Date” and “Author” (ID)System ID
is currently)System ID
andSystem Date
are currently)entry
node in the Data Source Included Elements listThis would allow for something like:
This would give us a little more native power over controlling entries written by different authors. It makes the XML a little more verbose, which is my only hangup, but maybe these could be optional in the Data Source Included Elements:
pagination
entry-metadata
title
etc.This could actually be done using an Extension. By hooking in to the ‘save entry’ delegate the extension could track this data itself. But having it baked in natively feels right, particularly making these meta attributes filterable/sortable in Data Sources.
What are peoples’ thoughts on this?