Misleading UI: `Modified` header in article list view

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Publish a new article.
2. View article list (/textpattern/index.php?event=list).
3. Check `Show more detail`.
4. Note `Modified` column time stamp.

What is the expected output? What do you see instead?
The `Published` and `Modified` time stamp for a newly-published article with 
zero modifications should not be identical. If the article has not been 
modified, as in the above example, the column should be blank.

What version of the product are you using? On what operating system?
4.5.5, Centos 5.

Please provide any additional information below.

Original issue reported on code.google.com by gaek...@gmail.com on 1 May 2014 at 2:08

[GoogleCodeExporter]

I'm not sure if this is an issue or not. As far as I can remember, Txp has 
always done this (or is it a regression?), as it follows a suitably UNIXish 
notation of created and modified. But just because it's always been that way 
doesn't mean it's right!

Although publication of an article isn't necessarily a parallel to a file 
write, there are precedents in the file system world:

* UNIX / OSX

> touch file.txt
> stat file.txt

All the 'accessed', 'changed' and 'modified' timestamps are identical (UNIX 
doesn't store a 'created' timestamp).

* Windows

1. Create text file.
2. Save it.
3. View 'Date created' and 'Date modified' columns in Windows Explorer: 
timestamps are identical.

But just because Textpattern mimics this behaviour at the database level to set 
the modified time the same as the created time on first save doesn't 
necessarily mean we should show it that way in the list.

On the Write panel, the 'modified by' line is omitted if the posted and 
modified times are identical. In a similar vein we could simply blank out such 
entries in the Article list panel and it would look as you wish. The issue will 
be if someone sorts by the Modified column and expects to see the 'empty' 
entries first: that won't happen with a simple omission of values from the 
table because the database query that performs the sort uses the real modified 
dates to determine order.

To effect the change properly, would require some SQL skulduggery to populate 
the returned record set with a blank modified value if the creation timestamp 
is the same as the modified stamp. That would allow sorting to work and the 
visual distinction you seek.

The question is: what are the benefits to authors / administrators of knowing 
that an article has yet to be modified from its original form? If we can nail 
down some real world scenarios where it makes sense to operate on, or otherwise 
distinguish, this set of articles, then it's valid to investigate ways to 
achieve that.

Thoughts anyone?

Original comment by stefdawson on 21 May 2014 at 12:49

[GoogleCodeExporter]

I'm happy to leave current functionality in place, even a new article has been 
modified (it's been modified from its non-existence to existance). As you say, 
this is how an OS handles this situation, and the list table is essentially a 
file manager.

Original comment by flaming....@mac.com on 21 May 2014 at 6:59

[GoogleCodeExporter]

First off, this is not a big deal - if this is how it's always been, I 
understand why.

As a site administrator, I am aware of <txp:if_modified> and <txp:modified> and 
use them regularly. If an article goes from not existing to existing (in Phil's 
example), <txp:if_modified> does not automatically evaluate to true - it's the 
_subsequent_ edit of the article that makes it modified.

This is the disparity in my view: one view says it's been modified (Articles -> 
Show more detail), one says not (<txp:if_modified> + <txp:imodified>).

Original comment by gaek...@gmail.com on 21 May 2014 at 7:56

[GoogleCodeExporter]

@gaekwad: good point regarding the tags. That is definitely a cognitive 
disconnect I hadn't considered.

Let me see if I can figure out a way to get the query itself to only return a 
modified timestamp if the created stamp differs.

Original comment by stefdawson on 21 May 2014 at 10:32

[GoogleCodeExporter]

True, but that's talking of something modified in the more traditional 
public-facing sense i.e. not a file list context.

I think that blank modified dates in the in article list table's modified 
'column' would be undesirable. An entry like 'Never' might work, but even then 
that may cause confusion in my opinion. There's no perfect solution for this.

Original comment by flaming....@mac.com on 21 May 2014 at 10:36

[GoogleCodeExporter]

Resolved by adding a .not-modifed class to dates of unmodified articles.

Original comment by flaming....@mac.com on 24 Jun 2014 at 9:26

• Changed state: Fixed