Opened 7 years ago

Closed 7 years ago

# Only show resources which changed since the last visit

Reported by: Owned by: Martin Scharrer Martin Scharrer normal WatchlistPlugin normal track unseen changes Steffen Hoffmann 0.12

### Description

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

### comment:1 Changed 7 years ago by Martin Scharrer

Status: new → assigned

### comment:2 Changed 7 years ago by 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.

### comment:3 Changed 7 years ago by 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.

### comment:4 Changed 7 years ago by 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.

### comment:5 follow-up:  6 Changed 7 years ago by 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.

### comment:6 in reply to:  5 ; follow-up:  7 Changed 7 years ago by Steffen Hoffmann

Keywords: track unseen changes added; seen removed

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.

### comment:7 in reply to:  6 ; follow-up:  8 Changed 7 years ago by Martin Scharrer

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.

### comment:8 in reply to:  7 Changed 7 years ago by 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.

### comment:9 Changed 7 years ago by 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.

### comment:10 Changed 7 years ago by Martin Scharrer

Resolution: → fixed assigned → closed

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

### Modify Ticket

Change Properties