[OJS 3.x] add user ID to user list in search page

Hello all, @asmecher , @NateWr , @ctgraham ,

How difficult would it be to add the User ID to the table listing of users?
I’m trying to find that template, but the code has become quite obscure to me lately…

The columns are currently defined in the UserGridHandler:

Not exactly analogous, but a plugin which modifies the grid to add a link based on the user id is here:

Also not exactly analogous, but search by the username is an enhancement request: Default user search does not include username · Issue #7217 · pkp/pkp-lib · GitHub
with anticipated implementation via refactoring user management:
[OJS] Slow queries on the user management page · Issue #6991 · pkp/pkp-lib · GitHub
so more changes are coming.

Hello @ctgraham ,

Thanks for the quick reply!

I added this to the code, and hope it’ll be included as a default, as user ID may be an important information for user management.

// Grid columns.
$cellProvider = new DataObjectGridCellProvider();

            // ID.
                    new GridColumn(

Can you share some specific use cases of where the user id would be valuable here?

Hello @ctgraham ,

Searching for users is faster using a specific value, rather than names and the such, as well as for editorial team control in external tools… I don’t recall exactly why we needed the ID, but it’s mostly to prevent confusion as well as checking duplicate users and finding them more easily manually in the database, contacting them and making sure they are duplicate records.

We have plenty of cases of very similar names, homonyms and people not using complete names. To merge a record we must be very certain that they are a duplicate record.

Also, if we need to remove a role temporarily from a user (mainly reviewers), to avoid listing and assigning them (while allowing them to keep access to the system), recording the user ID and Role ID are essential if we ever need to restore that access for whatever reason.

OJS is missing some “data” tables. Lots of information is “hidden” inside records, requiring lots of clicks to view. This is why we need external spreadsheets to control processes… Submissions are not handled immediately, responses take time and we need to keep track of what’s going on quickly. Otherwise, we lose a lot of time…

I’m thinking the username would be the better administrator-facing identifier for disambiguation, except in the case of direct database queries. But, even if ultimately using a database query, I think that query would benefit from joining the table of interest against the users table to get the username.

If the shortcomings which are causing you to maintain spreadsheets outside of OJS are not already described as feature requests, or are not already addressed in newer versions of the software, I would recommend posting about them in new threads here in the Community Forum.

Hello @ctgraham ,

I believe I have posted our feature requests regarding submission data viewing on the submission queue.