Feature request: Backend, Date for Entries

[ddeimeke]

In my opinion it would be a great idea to show the dates of the entries on the right hand side of the dashboard.

I geht a "vorgemerkt", in case an article is ready to be published at some point in time in the future, but I can not see the date.

[bauigel]

+1

[yellowled]

Can't promise this for Stable, will keep it in mind for Future.

[ophian]

For my ISO-8859-1 special chared testblog I do it like this (only a simple approach)

<a href="?serendipity[action]=admin&amp;serendipity[adminModule]=entries&amp;serendipity[adminAction]=edit&amp;serendipity[id]={$entry.id}" title="#{$entry.id}: {$entry.title|escape:'html':{$CONST.LANG_CHARSET}:false} ({$entry.timestamp|@formatTime:$CONST.DATE_FORMAT_SHORT})">{$entry.title|escape:'html':{$CONST.LANG_CHARSET}:false|truncate:75}</a>

[yellowled]

only a simple approach

Thanks, but since title is not very useful on touch devices, I'll see if I can come up with something that works on first glance.

[yellowled]

It should be pretty obvious that an entry is scheduled if it displays a date in the future, right? So I decided to just display that date and some extra info in a tooltip of the date badge.

That should do the trick.

[yellowled]

That's how it looks. Can't really display the tooltip in a screenshot, though. Fits the layout on all devices.

Edit: And of course, the date is lang specific.

[ddeimeke]

This is pretty nice and would help a lot.

What about showing the time for Draft articles as well (instead of using the word "Draft")?

The gray backgrounds states that the article is not online yet.

[ophian]

btw can you both access {if $entry.ep_is_sticky}?
I think this flag is missing in dashboard entries fetch...

[ophian]

OK, in dashboard overview.inc.tpl this should be {if $entry.properties.ep_is_sticky}, but it does not make real sense having it here at all. It will only work for drafts or futures though... and then these grey notices get somehow crouded.

BUG! And, If set as a draft, publishing will remove the ep_is_stick properties flag, since this action will only update the entries table, flushing but not updating serendipity_entryproperties. We have to make sure a dashboard publish entry action does not touch serendipity_entryproperties entries! Any ideas?

[yellowled]

(To seperate issues.)

[yellowled]

What about showing the time for Draft articles as well (instead of using the word "Draft")?

I don't think so.

1. How would we distinguish Scheduled and Draft? Both would have a grey box with a date in it. (Yes, we could use different colors, but the state of an article is very hard to communicate by color.)
2. I don't think the date of a draft is a useful information. I can see that for schedules articles (“When will this be published?”), but a draft could be published literally any time (whenever the user desires).

[ddeimeke]

@yellowled

There is a big green button titled "published" which shows that the article is a draft. In my opinion the button does not make any sense without the information about the date of the draft.

[yellowled]

In my opinion the button does not make any sense without the information about the date of the draft.

You are right, because all it does is publish the draft. What (I think) it should do is set the date/time to current and publish. The current behaviour of the Publish button doesn't make much sense, I think. See #262

However, I don't see the usefulness of a date of a draft. It is not necessarily the date the draft was last edited (you'd have to reset that manually, I don't think we store a “last edited” timestamp), but it's not necessarily the date the draft is supposed to be published at, either. Even if so, wouldn't you schedule an article if you already knew the date it's supposed to be published at?

Maybe I just use drafts differently than other people, but to me, a draft is something that will be published (or scheduled) once it's finished. So the publication date depends on the completion of the content, which is not necessarily tied to a date.

[ddeimeke]

I like that approach and I like to discuss that in #262

Keeping this in mind we would not need the draft status to be displayed.

Articles in the dashboard would be either articles coming in the future or being drafts. So the only information needed would be the future date or the publish button.

Good one!

[yellowled]

Keeping this in mind we would not need the draft status to be displayed.

Well, it doesn't hurt to display it, either. Also, we might decide to add other article states to the dashboard at some point. I think it's a good idea for the future to have a state indicator of some kind for any article.