Each person who works on a project gets their own user on the databases of that project's applications, through Ploi, the tool that manages the servers. Two actions in Users keep that in order: Sync Data checks every database and adds the access that is missing, and Change Database Password gives a person a new database password on every server. This guide explains what each one does, its risks, and what it leaves alone.
Both are in the admin panel. To reach it, open the menu at the top right and choose Go To Admin Panel; Users is in the Users group of its side menu. How servers and applications are kept is in Servers and applications.
Who should have database access
Both actions compare against the same rule. A database belongs to one application, and the application to one project and one environment:
- The company's top role and the super administrators have access to every database.
- Active project members who are Tech Lead, Project Manager or Product Owner have access to the project's Production and Development databases.
- Active project members in a developer role have access to the project's Development databases.
- Nobody else has access to Staging databases.
- People who are inactive or deleted have no access.
Only applications set up on Ploi, on a server with a Ploi Id, are taken into account.
Sync Data
Sync Data is a button at the top of the Users list. Only super administrators see it, and only they can open the page it leads to: anyone else who opens its address gets an error page.
It opens Ploi User Sync.
- In Scope, tick the servers to check, or click Select all servers. Clear selection unticks them all. If you tick none, every server is checked.
- Leave Force remote database-user recreation unticked unless you need it; see below.
- Click Synchronize Ploi.
It starts straight away, without a confirmation, and you see Ploi sync queued. It runs in the background and the page refreshes itself until it ends, so you can wait or come back later in the same session.
What a run does
In this order:
- Updates the roles of every active person, on all of them, not only the servers you chose.
- Takes every inactive person out of all the projects they still belong to. This is also not limited to the servers you chose, and those people lose their access to those projects' databases.
- On each database of the chosen servers, compares who has access with who should, and adds the access that is missing.
Access that a person has but should not is kept, not removed. The run reports it so you can decide what to do. A database that cannot be found on Ploi by its name is skipped and reported as failed.
The result
At the top:
- Status: pending, running, completed, partial (some rows failed) or failed, with the time it started.
- Rows: how many person and database pairs were checked.
- Corrected: missing access that was added.
- Preserved: access a person should not have, which was kept.
- Inactive Removed: project memberships removed from inactive people.
Console output shows every step with its time. Latest results has one row per person and database:
- User: the person and their database user.
- Database: the database, with its domain and server.
- Expected: Should have access or Should not have access.
- Actual: Has access or Missing access, before the run.
- Action: added, preserved or none, with a sentence explaining it.
- Final: Has access or No access after the run.
- Status: ok, corrected, preserved or failed.
With no rows, it says No synchronization details yet.
Force remote database-user recreation
This option is for a database user that is out of step on a server and will not take access normally. Before checking access, on each chosen server, it takes every person who should have access to at least one database there, removes their database user from every database on that server, and adds it back, with the password saved for them in Weblabor Admin, only to the databases they should have. The default accounts are skipped.
Use it with care:
- It touches everyone with access on the chosen servers, not only those missing it.
- While it runs, those people lose their database access for a moment.
- Access they had but should not have is not given back.
- If the password saved for a person is not the one they use, they have to use the saved one from then on. Change it with Change Database Password if needed.
What Sync Data does not do
- It does not remove access a person should not have.
- It does not change anyone's password, except through the forced recreation above.
- It does not create databases or set up applications; that is Execute on Ploi, in Servers and applications.
- It does not touch servers or applications without a Ploi identifier.
Change Database Password
Change Database Password is on a person's page in Users. Only super administrators see it and can use it.
- Open the person in Users.
- Click Change Database Password.
- Password comes filled with a random one. Keep it or type your own.
- Click Save changes.
You see Change Database Password action executed successfully. The new password is saved straight away, and the change on the servers runs in the background: one server after another, 30 seconds apart, on every server where the person should have access to at least one database. On each server, their database user is removed from every database and added back with the new password only to the databases they should have.
Before you click:
- Copy the password. Nobody is notified and the password is not shown again here; give it to the person yourself.
- Their old password stops working on each server as it is reached, and they lose access there for a moment.
- Access they had on those servers but should not have is not given back.
- If the person has no access anywhere, the password is saved and nothing changes on the servers.
It does not change the password the person uses to sign in to Weblabor Admin.