Page MenuHomePhabricator

Add wl_timestamp to the watchlist table
Closed, DeclinedPublic5 Estimated Story Points

Description

There have been many requests for this (or something similar to this) and this will be needed with the eventual goal of easy expiring of watchlist items.

It should be decided if this should be a timestamp of when the item was added to the watchlist or if this is the timestamp the watchlist item was last watched / touched? This will be important when tags are possible? When I add a tag should the timestamp stay the same or change? Page moves should also be considered.

This has been extracted from my comment at T124752#1998193

Event Timeline

Addshore set Security to None.

Change 271502 had a related patch set uploaded (by Addshore):
WIP Add timestamp field to watchlist db table

https://gerrit.wikimedia.org/r/271502

Addshore changed the task status from Open to Stalled.Mar 21 2017, 9:35 AM

How stable is this? Stable enough to deploy the schema on WMF before merging, or are there people that doesn't agree this extra field?

I think we want this field, but I'm worried that the intended semantics is still unclear.

In the patch by addshore, there is a comment that says "Timestamp the entry was created or last updated". Is there agreement that this is the intended semantics, as opposed to the intended time of expiry? If the timestamp is the creation/update time, additional information would be needed in the database to allow different e4xpiry periods to be implemented. Setting an expiry timestamp would allow different expiry periods to be implemented without any additional info in the database.

Technically, itb is not necessary to decide this before doing the schema change. However, re-interpreting the meaning of an existing database field is risky. I'd prefer to have a clear agreement on the semantics beforehand.

So as I see this the semantics described in the patch still hold true.
Having the date that a watched item was last added to the watchlist / modified allows users to easily remove very old watchlist items.
For the case of expiring watchlist items of course more information is needed and this could be provided in the form of another field containing the expire date (perhaps in a different table) or some way of tagging a field to for example expire in 1 month etc.

How stable is this? Stable enough to deploy the schema on WMF before merging, or are there people that doesn't agree this extra field?

I don't think we should rush on this and instead we can revisit this once the final bits of refactoring around watchlist things in core are complete (that were started in Feb 2016) and everyone's minds are refreshed & the idea of expiring watchlist items is actively being worked on again.

@Addshore Fine with me, but I want to make sure that this is really the semantics that is wanted/needed. The description of this ticket is a bit vague, and doesn't provide a concrete rationale. I'd hate us to add this, and then find out that we really needed something else.

I don't mean to block this - I just want to make sure that the relevant people are aware, and agree. Who will make use of this field? What do they say?

Change 271502 abandoned by Addshore:
Add timestamp field to watchlist db table

https://gerrit.wikimedia.org/r/271502

Marostegui subscribed.

Untagging DBA (but remaining subscribed) until there is an actionable for us (ie: schema change to do - https://wikitech.wikimedia.org/wiki/Schema_changes#Workflow_of_a_schema_change)
As the patch at T125991#2039065 got abandoned.

Aklapper changed the task status from Stalled to Open.Nov 1 2020, 11:36 PM

The previous comments don't explain who or what (task?) exactly this task is stalled on ("If a report is waiting for further input (e.g. from its reporter or a third party) and can currently not be acted on"). Hence resetting task status, as tasks should not be stalled (and then potentially forgotten) for years for unclear reasons.

(Smallprint, as general orientation for task management:
If you wanted to express that nobody is currently working on this task, then the assignee should be removed and/or priority could be lowered instead.
If work on this task is blocked by another task, then that other task should be added via Edit Related Tasks...Edit Subtasks.
If this task is stalled on an upstream project, then the Upstream tag should be added.
If this task requires info from the task reporter, then there should be instructions which info is needed.
If this task needs retesting, then the TestMe tag should be added.
If this task is out of scope and nobody should ever work on this, or nobody else managed to reproduce the situation described here, then it should have the "Declined" status.
If the task is valid but should not appear on some team's workboard, then the team project tag should be removed while the task has another active project tag.)

I'm declining this as the task creator as this was primarily created for T100508: Watchlist expiry: Watch pages for a specified time frame (2013) which has since been done by other means.
If someone else wants to take on this task for T67187: Show when pages were added to watchlist for example then please reopen it (and perhaps adjust the ticket chain)