User Admin configuration

Redmine offers two states: you are an administrator, or you cannot touch user accounts at all. That is a poor fit for a workspace where an office manager or a team lead does the joiner and leaver paperwork — granting them administration to approve one registration also grants them your settings, your projects, and the ability to make themselves permanent. This adds the missing middle: a standalone Users area that does the day-to-day work and nothing else.

On RedminePRO Cloud

Availability

Every plan.

Turn it on

Nothing to turn on. Grant the permission below and a Users entry appears in the top menu for whoever holds it.

User Admin appears as a heading on the role form but never as a project setting — a person does not belong to a project, so neither does the right to manage one.

Permissions

Administration → Roles and permissions, in the User Admin section:

It behaves as a global capability — holding it in any role in any project is enough. Administrators deliberately do not get the menu entry: they already have Administration → Users, which does strictly more. One door per person.

Settings

None. There is nothing to configure — the permission is the whole control surface.

Using it

1. Open Users in the top menu. Awaiting approval is the front page, because that is the queue with someone waiting on the other end.
2. Approve an account to activate it and send Redmine's own activation mail.
3. New user creates an account with the normal validation. The generated password is emailed to the person and never shown on screen.
4. Edit user covers name, email, language, notification preference and your user custom fields.
5. Lock a leaver; Unlock reverses it. There is no delete, deliberately — deleting a person rewrites history, and locking is reversible.
6. Send password reset sends Redmine's own reset link.
7. Groups adds and removes ordinary group membership.

Search matches on login, name or email. Status filters to Active, Awaiting approval or Locked.

What a workspace user admin can never do, enforced on the server on every request whatever the page happened to render:

• See or touch an administrator. Administrator and service accounts are excluded from the query itself, so they never reach a list, a search or a form. A direct address to one returns not-found rather than forbidden — a refusal would confirm the account exists and let someone map your privileged users.
• Grant administration. There is no such field in the form and the parameter is not accepted, so submitting it by hand does nothing.
• Edit their own account here. Their own record opens read-only with a link to My account, and a write to it is refused. Every escalation story starts with an actor acting on itself.
• Delete anyone. There is no route at all.
• Reach anything else. No settings, no projects, no roles.

Plan usage

When the platform feature is present the list shows how many of your plan's seats are in use. It is a display only — the platform does the enforcing, and duplicating that here would mean two places to keep in step.

Troubleshooting

The Users entry is missing. The account either lacks the permission or is an administrator, who is sent to Administration → Users instead.

An account is not in the list. It is an administrator or a service account. That is deliberate and cannot be configured away.

Send password reset is not offered. Redmine's own password rules forbid it for that account — either lost-password handling is switched off for the workspace, or the account authenticates somewhere else and its password is not Redmine's to reset. The button is hidden and the action refused, rather than offering something that would fail.

Someone wants to delete an account. That stays with an administrator. Locking is the supported answer and it is reversible.