Search

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:

  • expand sym_entries to include in addition to System Date, a “Last Modified Date” and “Author” (ID)
  • make all of these available as Data Source filters (only System ID is currently)
  • make all of these available as Data Source Output Parameters (System ID and System Date are currently)
  • make all of these available as (optional) attributes on an entry node in the Data Source Included Elements list

This would allow for something like:

<entry id="123" created-date="2009-07-16" created-time="13:16" updated-date="2009-07-16" updated-time="13:17" author="4">
   ...
</entry>

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?

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.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details