Short answer: yes, this is possible - but not by "copy-pasting fields" in the way MySQL-era instincts suggest. PostgreSQL and uzERP are stricter beasts. You'll need to work with roles, permissions, and uzERP's own user tables, not just flip a boolean and hope.
Tell it like it is: this is recoverable, but do it cleanly or you'll leave a ghost in the machine.
First, the lay of the land (important)
There are two layers of authority here:
PostgreSQL roles
- Who can connect
- Who can read/write tables
- Who can alter schema
uzERP application users
- Stored in uzERP tables
- Control what the app lets you see and do
- Admin database superuser
You don't need to make your DB user a PostgreSQL superuser to regain uzERP admin access - and you shouldn't, unless this system is already a lost cause.
Tools: what to install on Windows
Yes, download an admin tool - but use one that understands Postgres properly:
Recommended
- pgAdmin 4 (official, safest)
- DBeaver (excellent UI, cross-DB, my personal favourite for forensic work)
HeidiSQL technically supports Postgres now, but it's still MySQL-brained. I wouldn't trust it for permission surgery.
What NOT to do
- Don't edit random fields blindly
- Don't hash a password manually unless you know uzERP's exact hashing method
- Don't grant PostgreSQL SUPERUSER unless absolutely necessary
- Don't assume "admin" is just a column called
is_admin (it often isn't)
That's how systems rot.
The correct recovery strategy (clean and reversible)
Step 1: Inspect uzERP user + role tables
In pgAdmin/DBeaver, locate tables typically named something like:
users
user_roles
roles
permissions
Exact names vary by uzERP version, but you'll find them quickly.
Look for:
- An existing admin user
- A role that clearly maps to admin privileges
Example queries:
SELECT * FROM users;
SELECT * FROM roles;
SELECT * FROM user_roles;
You're looking for patterns, not guesses.
Step 2: Compare, don't copy
Find:
- Your finance user
- The admin user
Compare role mappings, not raw fields.
Often it looks like:
user_id | role_id
If admin has role_id = 1 and your user has role_id = 3, that's your lever.
Step 3: Safest option - grant admin role to your user
This is the least destructive path:
INSERT INTO user_roles (user_id, role_id)
VALUES (<your_user_id>, <admin_role_id>);
Or, if already present:
UPDATE user_roles
SET role_id = <admin_role_id>
WHERE user_id = <your_user_id>;
This preserves:
- Audit trails
- Password hashes
- Application expectations
Step 4 (optional but wise): Reset admin password via DB
If you want the original admin account back, inspect how passwords are stored.
Check the column:
SELECT password FROM users WHERE username = 'admin';
If it looks like:
$2y$... bcrypt
{SHA} legacy
- Long hex custom hash
Best move:
- Log in as your newly promoted admin
- Reset the admin password through uzERP's UI
That way you don't fight hashing algorithms in the dark.
PostgreSQL permissions (only if blocked)
If your DB login can read tables but not write:
GRANT UPDATE, INSERT ON users, user_roles TO your_pg_role;
Or temporarily:
ALTER ROLE your_pg_role WITH SUPERUSER;
...but revoke it immediately after:
ALTER ROLE your_pg_role WITH NOSUPERUSER;
Use power like a scalpel, not a hammer.
Reality check (no sugar-coating)
- uzERP was not designed for casual DB meddling
- But PostgreSQL access is the master key
- This is a legitimate recovery path, not a hack - assuming you're authorised
And frankly: running Postgres on Windows already tells me this system needs adult supervision.
Forward-thinking advice
Once you're back in:
- Create at least two admin users
- Document DB + app access separately
- Export role mappings
- Consider moving Postgres off Windows if uptime matters
- Add a quarterly access audit - even a simple checklist
Entropy always wins unless you push back.
If you want, next we can:
- Identify the exact uzERP schema you're on
- Craft version-safe SQL
- Or build a one-time recovery script you can archive and forget
A system should bend under the right hands - not break.
