Getting into Odoo

An environment is running and you need to log into the Odoo behind it. The credentials are not admin / admin, and that is on purpose: an environment restored from a catalogue template would otherwise ship with the best-known password in the industry.

The environment's own administrator

The platform generates an administrator login and password when the environment is provisioned, and the Odoo administrator panel on the Configuration tab reveals them.

They are fetched on demand, not loaded with the page. Nothing about the credentials travels to your browser until you press the button, which keeps them out of response bodies, browser caches and any screenshot of this tab taken for another reason.

Seeing them requires environments.config — the same permission as changing the environment's settings, because an administrator password is a setting in every sense that matters.

One refusal is worth recognising. An environment created before this rotation existed has no generated password to show, and the panel says so and tells you to redeploy. That is a real answer, not a failure: redeploying is what generates one.

What the credentials are, and are not

They are the Odoo administrator account of that environment's database — the account you use to install a module by hand, look at a record, or fix something an update left half-done.

They are not a way in for your team. Everyone who works on Odoo should have their own Odoo user; sharing the administrator account is how you end up unable to tell who changed a setting. Use it to bootstrap, then create real users.

Nor are they your platform login. Your RollBackk account, your team and your permissions are a separate system entirely — the environment guide on team roles covers that side.

When a client cannot get in

On a multi-tenant environment each client instance has its own administrator, and "my client has lost their access" has two answers. They look similar and they are not interchangeable.

Resend the address changes nothing at all. It emails the client their login page again. Most of the time this is the real problem: they still have their password and simply cannot find the URL. Resetting in that situation would break a working login to fix a problem they did not have.

Issue a new password is the only recovery when the password itself is gone. Nothing can be re-sent, because nothing was kept: the password was generated, applied to their Odoo and never stored, so neither the platform nor a stolen copy of our database can read a client's credentials. Issuing a new one stops the old one working, immediately.

Try the first before the second. It is free, and it is usually enough.

Both need tenant.manage, and both are on the client's own detail panel rather than in a bulk action — resetting a password is a conversation with one customer, not an operation on a list.

Trials, while you are there

The same panel settles a trial for one client: extend it by a number of days, or lift it entirely.

Days count from now, not from the original signup. "Two more weeks" said on a call means fourteen days from that call, which is what makes the number on the screen match the sentence you just said.

A trial belongs to a client rather than to the signup link they came through, because by the time it matters it has become a commercial conversation with that one customer.