make db-actions:delete-user safer

[maxlath]

by prompting for a confirmation if the target user displays signs of activity

The current use case of this script is to easily delete spam accounts, but when you get to the point to delete users like you merge authors, that can get scary, especially as there is no revert button

[jum-s]

cool !
Except for 0762a38 , which is doing many things but its server/controllers/user/lib/get_user_stats.js that i think is not a good idea

1. technically : it doesnt seem very maintainable (every time a user document changes this file will have to be updated)
2. politically: i would like to ideally restrict sysadmins' access to user details, this is not going in this sense. I understand its an aggregation/sum but still, if an admin want some details, they go to the user's page. From there within one click, they will have access to _id, bio, roles, created, items, shelves, contributions

also total is a sum of too many apples and oranges that doesnt make sense to someone who doesnt want to read the source code, this total number can only make sense if you compare it to total of other users

I would be for deleting get_user_stats or at least put in another branch

[jum-s]

see comment above

[maxlath]

1. technically: I would on the contrary bet that the added maintenance cost would be quite minimal: all those functions are already consumed elsewhere in the app, so we would be paying the maintenance cost for breaking changes anyway, and I would expect the marginal cost for updating the contract in 2 modules instead of 1 to be negligible. As this is only read operations, the worst case scenario would also be far from a catastrophe: there is a breaking change and the maintainer doesn't update this module => an admin runs the script, and the script throws an error or gets undefined or NaN instead of one of those counters. This worst case could be mitigated by adding a test, but I'm not sure it's even worth it
2. politically: I need a concrete example where this kind of aggregated data would be a problem. Here is a concrete example where the approach you propose would be lacking: a user has 100 private and network-only items in their inventory and 5 ongoing transactions, but no public items: from their user profile, if they happen to have a URL in their bio, the risk of taking them for a spammer and deleting their account during a batch of spammer weeding is extremely high: the admin going through a list of 50 accounts that looks like spammers (see /tmp/users_ids_to_delete on the prod server) needs a quick way to know what is and what isn't spam, those counts of apples and oranges would help a great deal. (What we could do to reduce the amount of spammers would be another topic). Those counts help the admin to get a quick idea of what is going on with an account, and would be very valuable moderation tools. Note that all those data and waaay more are already accessible to any admin with database access, it's just much more work to craft the queries to access it. It is a concern and a great responsibility, but I don't think that this is the way to address it
3. the total is just there to be able to do if (total > 0), which is way quicker than if (a > 0 || b > 0 || c > 0...
4. I'm not far to think that "someone who doesnt want to read the source code" should not be admin* ;)

Edit: * in the current state of the project

[jum-s]

i dont think that's negligible : if we add script like this per week, after 2 years any change would be a pain.

As you mentioned, i would rather setup a deleting inactive accounts policy, instead of giving the power to sysadmins to easily inspect if a user is rather public or private.

It should always be a lot of work to dig in users private data.

It's not the first time you mention this fight against bots, what about opening an issue about it to collectively find some way to address it ?

[maxlath]

issue opened: #503

[maxlath]

I pushed the 2 non-controversial (including 1 somewhat critical) commits to master, to let this PR contain only the controverted commit