Add annual reports for accounts #28693
Conversation
7ceca30 to
de8c7f5
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #28693 +/- ##
==========================================
- Coverage 85.08% 84.91% -0.18%
==========================================
Files 1038 1055 +17
Lines 28159 28332 +173
Branches 4533 4545 +12
==========================================
+ Hits 23959 24057 +98
- Misses 3039 3114 +75
Partials 1161 1161 ☔ View full report in Codecov by Sentry. |
unless I'm missing something, this doesn't seem to be mentioned anywhere on the roadmap or any currently open issue? |
|
We have an internal bug tracker for project-wide features, and this is what MAS-213 references. The public roadmap is generated from it, but has not been updated in a while (I need to look at how to automate it). |
de8c7f5 to
5d75965
Compare
There was a problem hiding this comment.
I have made a few inline comments. In addition, I am concerned about two things:
- I'm concerned with the server load of going through each account's year of posts, this may expensive if your instance has prolific posters
- I'm concerned with the fact this stores user metadata of a somewhat personal nature (such as most used app, most reblogged accounts, interacted with accounts, …) that the user may not know about (because of not using a client that makes use of this API) or may not delete (the current implementation does not provide any way to remove them from the database) save for outright deleting their account
c2251a2 to
c0a4a66
Compare
There was a problem hiding this comment.
I'm still not a fan of the popularity-based information, and I still have concerns regarding the performance cost of generating a large number of these reports, and regarding the fact this essentially holds (small amounts of) user metadata the user can't remove unless they outright delete their account.
However, since these reports are currently not automatically created and can only be manually created through a Rails console, these concerns are not blocker for now, but they probably need to be addressed before those reports get generalized.
c0a4a66 to
162e695
Compare
|
Last change adds a percentile calculation based on posts created as per Sam's comment. |
There was a problem hiding this comment.
Repeating my previous review as it is still relevant:
I'm still not a fan of the popularity-based information, and I still have concerns regarding the performance cost of generating a large number of these reports, and regarding the fact this essentially holds (small amounts of) user metadata the user can't remove unless they outright delete their account.
However, since these reports are currently not automatically created and can only be manually created through a Rails console, these concerns are not blocker for now, but they probably need to be addressed before those reports get generalized.
|
There's absolutely no information as to what this feature is about, and we have no idea what we're merging into our forks at the moment; is this some sort of "mastodon wrapped" feature? And if so, could it be turned off? There is absolutely no reason for this to become a staple feature for a server, it only adds to the cruft and maintenance. |
|
This is an experimental feature, to power an eventual yearly recap feature. This code can not be triggered in any way at the moment, except through the console, and will be built upon later. Nothing is defined yet, but I can see the need for a server setting to disable it. |
|
Marking my surprise that the comments by @ClearlyClaire are not even acknowledged. This is not only an additional server burden, it is also personal and potentially GDPR-relevant info that users will not be aware is being collected and that they should have power to delete or opt out of. |
|
As I said above, this is an experimental feature that can not be triggered except through the console. The comments above have not been ignored, but work on the feature has stopped for now. It will evolve in a future PR (or removed). |
Fixes MAS-213