Page MenuHomePhabricator

Moving task in the same column of the workboard causes its update
Closed, InvalidPublic

Description

Naturally sorted workboard
Move task in the same column up or down (=no changing of priority, no changing of column...)
It triggers updating of its last-updated time

It should not, since no action has been performed - changing the order on workboard isn't recorded in task history.

Event Timeline

Danny_B created this task.May 19 2016, 9:23 AM
epriestley closed this task as Invalid.May 19 2016, 12:22 PM
epriestley added a subscriber: epriestley.

"Last Update" is low level, and includes some actions which do not appear in the task history. This is expected.

But moving on the workboard is no update at all... It is null action.

In fact it breaks various monitoring/statistics depending on last update, such as longest time untouched (== no comment, no projects/tags changed, no workboard column shift, etc...) tasks, response time etc...

In fact it breaks various monitoring/statistics depending on last update

These are third-party extensions, not other upstream applications, right?

Why do you consider this to be a bug in Phabricator rather than in those extensions? Does the documentation say "this field is updated only when a 'meaningful' update is made to an object, and you can and should rely on it to have this behavior when extracting data from Phabricator" somewhere?

These are third-party extensions, not other upstream applications, right?

Yes.

Why do you consider this to be a bug in Phabricator rather than in those extensions? Does the documentation say "this field is updated only when a 'meaningful' update is made to an object, and you can and should rely on it to have this behavior when extracting data from Phabricator" somewhere?

It's logical - you can not build reasonably working application on wrong dataset. One would assume, that maybe in future, Phabricator (either directly or via an extension) will have support for such stats too (as it currently already has some stats such as burnout charts or so...)
Inability to do such stats due to unreasonable dataset below makes Phabricator (otherwise good application) useless for teams which are trying to improve (read: shorten in this particular case) the task life-cycle - and that's pretty much every team since noone wants to have long time untouched tasks without any action taken... ;-)

Also, knowledge of existence of this issue may lead to abuse of it in form of manipulating many tasks on boards this way which will cause the really updated tasks roll out of sight on lists sorted by last update.


I admit I did not look at the relevant code, but my assumption is, that fixing of this should not be more difficult than adding a single condition to the relevant place.

It's logical - you can not build reasonably working application on wrong dataset. One would assume, that maybe in future, Phabricator (either directly or via an extension) will have support for such stats too (as it currently already has some stats such as burnout charts or so...)

See also T1562 and T4171

Third-party applications which assume dateModified means "last 'meaningful' update" are written incorrectly. It does not mean that, it is not documented to mean that anywhere, and it is clear from the code that it doesn't have this behavior. It is unreasonable to assume that the only possible purpose of this field is metric extraction. This field is a low-level field which serves a different set of goals. It explicitly does not serve metric extraction goals.

Third-party applications interested in specific metrics like "last 'meaningful' update" should read the transaction log for the most recent "meaningful" update's creation time, not the dateModified field.

This is the strategy used by what infrastructure does exist today in T1562, and the planned pathway forward in the upstream.

I admit I did not look at the relevant code, but my assumption is, that fixing of this should not be more difficult than adding a single condition to the relevant place.

It is much more difficult than this, and this is not the only type of change which modifies dateModified without producing an accompanying "meaningful" transaction. If we redefined dateModified to mean "last 'meaningful' change", we would need to update approximately 225 objects which have this field, and review all of the possible edits to all of those objects and determine if they were 'meaningful' or not, then update all of those edit pathways to mark or not mark the object as modified.

Beyond this, the definition of "meaningful" is subjective. Is a title edit meaningful? What if it only changes one letter? What if it only changes one punctuation mark? Is adding a subscriber meaningful? Is editing a custom field meaningful? Does it depend on which custom field it is? Is merging another task in meaningful? Is adding a dependency meaningful? Is mentioning a task elsewhere meaningful? Is moving a tile on a workboard column really not meaningful? Different users will have different answers to these questions, which is one of the reasons that we do not try to compute a "last 'meaningful' update" column: this is too poorly defined to have a single consistent value.