600118 - add delta_ts column to profiles (provide a last modified timestamp for users)

Status: NEW

(Bugzilla :: User Accounts, enhancement)

Description

[:glob ✱]

it would be useful to have a last-modified timestamp for users.

Comment 1

[Max Kanat-Alexander]

Make sure to also expose it in WebServices as last_change_time for users.

Comment 2

[Frédéric Buclin]

What would affect delta_ts? Which user attribute(s)?

Comment 3

[:glob ✱]

(In reply to comment #2)
> What would affect delta_ts? Which user attribute(s)?

i'm thinking of updating the delta_ts in:
  $user->create()
  $user->update()
  cryptpassword and name changes in userprefs.cgi
  cryptpassword update in auth::verify::db
  cryptpassword and email changes in token.cgi

Comment 4

[Frédéric Buclin]

I don't see the point to update delta_ts when the password changes. You are not explicit enough in comment 0 about why profiles.delta_ts would be useful (and IMO, should be clarified), but my guess is that you want it for bug 594962, in which case there is no reason to invalidate the cache when the password changes. This doesn't play *any* role in the bug report display.

And we shouldn't blindly update delta_ts when update() is called; only when something which is significant and can impact something else, like bug 594962, is concerned.

Comment 5

[Max Kanat-Alexander]

Frédéric: I understand where you're coming from, but I think that design decisions like this should be made more on a slightly theoretical basis than on a "what exactly does it get us right now" basis. That is, logically a "delta_ts" field should be updated any time anything about the user object changes. Since that would be the general expectation, and that would be simplest from the perspective of future developers, we should just do that.

Comment 6

[Frédéric Buclin]

We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.