Not a strong opinion, but maybe instead of login we could say a more general "last user activity"?
And we could remove never_loggedin for now.
What do others think?

It depends a bit on what we want to measure. In my opinion, the most interesting are user actions, which are typically not automatised.

Here are some examples (it should already now be more or less like that, but some points need to be double-checked):

Catching:

• Explicit Web login (and only explicit)
• Mark as read, favourite, label (from Web or API)
• Add/remove feed/category (from Web or API)
• Change settings
• Add/remove user (for admins)

Not catching:

• API synchronisation (often automatic)
• Viewing FreshRSS RSS outputs (typically automatic)
• Anonymous views
• Pull-based synchronisation by cron
• WebSub updates
• Automatic database cleaning

I am not sure if this is getting overcomplicated? The original issue was to fix a use case whereby an admin can quickly see which of their users are using the system. Last login is an ideal way to measure that. Even if they logged in and then straight back out, they are still using the system.

This is why my initial approach was recording the login time as opposed to when the configuration file was last modified.

I have also just discovered, when the actualize script runs, all the configuration files are touched. Therefore, you cannot rely on the configuration file modified time. Background processes modify it.

I propose we either put the last_login value back in the user config, as per my original PR or leave this issue until we have a user table.

My last post was only to explain the choice of the wording, not to ask for more work :-P
For instance, you might have an active user, using solely the API (e.g. from a mobile app), and never (or rarely) logging in. Therefore the login date is not a robust indication.

My last post was only to explain the choice of the wording, not to ask for more work :-P
For instance, you might have an active user, using solely the API (e.g. from a mobile app), and never (or rarely) logging in. Therefore the login date is not a robust indication.

I see your point. How do you want to proceed with this? I don't think the file modified time can realistically be used. As I said previously, it can be modified by background processes.

I think we should complete this PR with the file modified time (which should still work OK even if not perfect), and wait for another PR to improve the storage of this information in a dedicated field in DB

@equinoxmatt I have made a few changes. Could you please double-check whether that works for you?

Merging, but feedback still welcome

@Alkarex Sorry for the delay, the changes LGTM 👍 thansk for your help on this.

Does this last user activity field updates when users synchronize their feed using RSS clients only?

@alexkuang0 The last user activity is updated only when there is a non-automatic action such as marking an article as read, as favourite, modifying a feed / category, etc. independently of whether this is done through the Web interface or through the API.
Login in through the Web interface is also counted as an activity.