Only show resources which changed since the last visit

[Martin Scharrer]

There should be a switch to allow to only show the resources which changed since the last visit of the watchlist.

[Martin Scharrer]

(In [8803]) Made first changes for a selectable date/time range included since last visit check-box. HTML layout is finished by JS-code is still TODO. See #7664. See #7649.

[Martin Scharrer]

Should the 'last visit' be the last time the user viewed the watchlist itself or the last time the user used Trac? The last visit to Trac is only updated once every 24h.

[Steffen Hoffmann]

Actually I did not assume, that someone would be able or willing to re-check all watched resources in one session. So what is required from my point of view, is tracking for visits to watched resource itself.

I saw, that watch/unwatch ctxtnav links appear according to user selection, so there must be already a check running against watchlist db, right? Why not update a to-be-invented "seen" column in the same run? That was just, what I guessed should be technically possible, no idea of any caveats in a real implementation.

[Martin Scharrer]

Ok, I see I understood this quite different.

Yeah, your idea requires a new column in the watchlist table to store when this resource was last visited. As you already states, this value can be updated in the handler for the context navigation bar. I can implement this.

Another questions: Should this filter be static, e.g. requires a reload of the watchlist, or dynamic using JS and the checkbox in the footer? In the first case an new option for it could be added under preferences.

[Steffen Hoffmann]

Replying to martin_s:

Ok, I see I understood this quite different.

Yeah, your idea requires a new column in the watchlist table to store when this resource was last visited. As you already states, this value can be updated in the handler for the context navigation bar. I can implement this.

Great, really.

Another questions: Should this filter be static, e.g. requires a reload of the watchlist, or dynamic using JS and the checkbox in the footer? In the first case an new option for it could be added under preferences.

No need for a static setting, even the contrary: Always pre-load all entries and dynamic hiding would be much more elegant and useful IMHO. But I'm not sure, how this plays with the paging code on dynamic table update. There could even be the case of 100+ watched resources in a realm and empty list of watched resources, if selecting "only show unvisited changes", you see?

Do you envision to remember the last setting of that checkbox - would be good have this stored, i.e. as another user preference on the fly or at least kept for consistent display within the a session.

[Martin Scharrer]

Replying to hasienda:

Another questions: Should this filter be static, e.g. requires a reload of the watchlist, or dynamic using JS and the checkbox in the footer? In the first case an new option for it could be added under preferences.

No need for a static setting, even the contrary: Always pre-load all entries and dynamic hiding would be much more elegant and useful IMHO.

I think the same. On the other side "static" server side filtering would be probably faster and also work if the user switches JS off.

But I'm not sure, how this plays with the paging code on dynamic table update. There could even be the case of 100+ watched resources in a realm and empty list of watched resources, if selecting "only show unvisited changes", you see?

The new JS-library for table supports filtering, sorting and paging at the same time very well.

Do you envision to remember the last setting of that checkbox - would be good have this stored, i.e. as another user preference on the fly or at least kept for consistent display within the a session.

Yeah, that is already implemented using cookies.

[Martin Scharrer]

There would also be the option to load the table data using AJAX and therefore send dynamic filter commands to the server which only delivers the data which is actually shown to the user. This would speed things up a little when there are a lot of resources on the watchlist. Loading a long table first and then activating the filters might take a second or longer.

[Martin Scharrer]

I implemented this now. Check out [8891] or later and have a look.

Please note that the DB table schema changed and there is now upgrade code from the last develop version, so you must drop the tables manually. There is a function for this in db.py. I will update the WatchlistPlugin page to hold some "Uninstall" information.

[Martin Scharrer]

This seems to work nicely. As already mentioned in another ticket there is the task of telling the user how the UI works.