mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
[Enhancement]: Display last used app (and version) for users in the Users' list #457
Assignees
adam (Adam Melkus)
Clear assignees
adam (Adam Melkus)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/audiobookshelf#457
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @raviwarrier on GitHub (Jun 14, 2022).
Describe the feature/enhancement
As a hypothetical, if the above user complains something isn't working, it would be nice to go into their user profile to see what app (web, mobile - android/iphone, windows, etc.) they were using when the problem occurred and what was the version of that app (in case, the solution is to tell them to update their app, or if I need to pass it on to developers as a bug or help request).
@jmt-gh commented on GitHub (Jun 17, 2022):
This should be easy enough. For what it's worth, this information is already available in aggregate and filterable by user at
YOUR_URL/config/sessions:@advplyr commented on GitHub (Jun 18, 2022):
I think we need to log user sessions (not to be confused with listening sessions). A user session would be when the user logs into a client. When a user logs into a client we should be sending the device data also and store this in the db so the server admin can see login/logouts and not just playbacks.
I may have already made a data model mistake by naming the listening sessions db "sessions" OR we could store both user sessions and listening sessions in the same db. I'm not sure we will need to think on this.
As per your original request I think we could easily show the device info of the last user listening session.
Hopefully I didn't make that too confusing..
@raviwarrier commented on GitHub (Jun 18, 2022):
I had to pause my playback and read it twice. So, i guess it was confusing. 😊
On a tandem note, from a privacy point of view, aren't the listening sessions a bit much? As an admin, yeah, i would like to see who logged in/out and listened to what and for how long and on what device and from where; but I'm thinking as a user, i wouldn't want someone to know all that, even if that person was a friend or a relative (which is what I am to my users).
At some point, people are going to realise this violation/intrusion and demand/request a change. I certainly would do it now if I was just a user.
Here's what I would do if I were you:
Only display info that the admin might immediately need to determine course of troubleshooting action - like device and app version number.
Create an export/share logs to admin function for the users that would, in one click, share it with the admin when requested/needed.
This way you maintain privacy of users and also create a system that can help admins access user logs only when permitted (inclusively by having it shared with them).
@advplyr commented on GitHub (Jun 18, 2022):
It's the same info that any website or app can see so I'm not sure what you mean. We could add options to purge and auto-remove listening sessions after some time.
@raviwarrier commented on GitHub (Jun 18, 2022):
I know that the data collected is more or less the same that most sites would collect.
But the circumstances are different. Knowing/guessing that some system/stranger knows what you are reading v a family member/friend knowing what you are reading elicit very different feelings related to privacy.
To clarify with an example: one wouldn't be too concerned about a personal diary lost in another city/country and read by a stranger as they would be about misplacing their diary in their brother's or parents'room where it could be read.
Another case: I wouldn't care if Amazon knew i read adult fiction, but would definitely care if my friend who's server i access knew that I was (least bit, it might be embarrassing).
Hope that clarifies what i mean by privacy issue of collecting listening sessions data.
@advplyr commented on GitHub (Jun 18, 2022):
Even without saving the library item with the listening session data we would still be storing the current progress for the user on each item. Without displaying it in the web app this would still be visible in the logs and the db storing media progress.
@raviwarrier commented on GitHub (Jun 19, 2022):
I guess that's they way the system is built. My intention was to just highlight that somewhere in the future, if and when ABS becomes a primary system for personal libraries, people might start wanting more privacy. You can ignore the privacy issue for now, as long as it's somewhere in the back of your head for a potential problem to deal with/feature to provide.
@advplyr commented on GitHub (Jul 21, 2023):
Added in v2.3.0