I recently updated to 3.2.1 and one of my users mentioned that when creating a log the list of owners got really long. I’m not sure if this is related to the recent updated or if it is older and just now noticing but looks like in the owner section of a log it is listing active and inactive users. Maybe this should be filtered to only active people?
At the same time I informed them they do not have to select the person if they are just selecting themselves as that is the default. When showing an example to them I found a pile of other inconsistencies and odd behaviors around people.
Me logged in as the account admin I can see the owners of the logs as myself (nick) and the other user (danielle) as they should be.
When filtering logs in /logs It shows a list of only the active people and not inactive, yet me as the admin is not listed in the available people to choose form. This is the same on my login and the other user login.
In filtering assets in /assets all people active and inactive including myself are visible.
When going to /people I do not see myself listed at all, but /admin/people I am listed here.
Maybe this is an issue with my install, intended behavior I don’t understand, or bug?
Im sure some of this is related to me being an instance administrator and using this for everyday work and maybe I should not be doing this? Is there a way to change the admin to another account? Or maybe this is not relevant?
Bingo. I believe we hide the user with ID = 1 from these lists and other places that users are shown, or it might even be a drupal core restriction. So yea, you should create a new user for your everyday work.
A good question. We have the new account_admin module + role you can provide users and they can still do some of the instance admin-y things like enable modules and create new users. But I’m not sure the best next step in your situation… ideally create a new user for your everyday work, but then how do we update that old data… hmm… I guess for assets and logs you could use the “Assign owners” bulk action to try and change as many of these as possible?
Ah yeaaaa thanks for making a forum topic about this @BOTLFarm. We sort of have an implicit “always create a lower-level user” rule, but that isn’t really spelled out explicitly anywhere right now… and we haven’t documented what happens if you use user 1 like this.
Hmm I don’t think this changed recently… but I definitely agree we should filter out inactive users. This might be worth opening a dedicated bug report for. There are a few places where lists of users are shown, so we should make sure to check and fix all of them if necessary.
The technical reason for this is because they do not have access to view your user at all… so from their perspective you don’t exist. IIRC this is Drupal core behavior - not farmOS specifically - so we can’t change it I don’t think.
Hmm I would expect these to behave consistently, so that’s something I’ll want to look into. In both cases user 1 should be hidden. This sounds like a bug.
This is expected behavior when you are logged in as user 1. Only user 1 can see /admin/... pages. farmOS provides the /people page for normal users, but Drupal core provides /admin/people for admins.
@paul121’s suggestion of using the bulk assign action to reassign all logs and assets would work. It might be a bit tedious, though. And it won’t change the actual author of records or revisions (farmOS also records which user authored records in addition to who “owns” them).
So if you want to completely rewrite history, to make it look like you never used user 1, you can run some SQL queries to replace ALL instances of user 1 with your new user ID everywhere in the database.
First, rename your “Nick” user to “Admin” or something like that. Then create a new “Nick” user, and copy the user ID. Then, these queries should update all references to user 1 in your assets and logs. These examples assume that your new user ID is 3, but change that to the actual ID of the new user you create:
These will update the author of all assets, logs, quantities, files, and taxonomy terms (including revisions):
UPDATE asset_field_data SET uid = 3 WHERE uid = 1; UPDATE asset_field_revision SET uid = 3 WHERE uid = 1; UPDATE asset_revision SET revision_user = 3 WHERE revision_user = 1; UPDATE log_field_data SET uid = 3 WHERE uid = 1; UPDATE log_field_revision SET uid = 3 WHERE uid = 1; UPDATE log_revision SET revision_user = 3 WHERE revision_user = 1; UPDATE quantity SET uid = 3 WHERE uid = 1; UPDATE quantity_revision SET revision_user = 3 WHERE revision_user = 1; UPDATE taxonomy_term_revision SET revision_user = 3 WHERE revision_user = 1;
These will update the owner of all assets and logs (including revisions):
UPDATE asset__owner SET owner_target_id = 3 WHERE owner_target_id = 1; UPDATE asset_revision__owner SET owner_target_id = 3 WHERE owner_target_id = 1; UPDATE log__owner SET owner_target_id = 3 WHERE owner_target_id = 1; UPDATE log_revision__owner SET owner_target_id = 3 WHERE owner_target_id = 1;
That should update everything, if you want to be super thorough.
Of course, maybe that’s overkill for your needs, and just updating “Owner” would suffice. I figured it was worth going through and documenting everywhere that the user ID ends up getting stored for future reference anyway.
I have started to recently see this mentioned here and there around the forum in passing but looking at documentation I could not find anything so was not sure. Thanks for clarifying.
With a small operation we don’t do a lot owners so I can make this workable with the bulk actions.
I was just looking at that myself, where would it be best placed… I think it makes sense at it own sub-section In ‘/hosting/install/’ after the Cron section.
Or if there are other things like this that should be done right away maybe a new section under hosting called ‘Initial Setup’. It has been a while since I initially set up so I don’t recall what else might need to happen right away.
