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:

1. PostgreSQL roles

   • Who can connect
   • Who can read/write tables
   • Who can alter schema

2. 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.

Since you are on Windows, the process involves using the PostgreSQL command-line tool (psql) or the pgAdmin GUI if installed. The following steps assume you are using the command line, as it is often faster for direct queries.

Phase 1: Access the Database

1. Open Command Prompt or PowerShell as Administrator.

2. Navigate to the PostgreSQL bin directory. If psql is not in your system PATH, you will need to find it. It is typically located here:

   cd "C:\Program Files\PostgreSQL\14\bin"
   

   (Note: Replace 14 with your installed version number, e.g., 10, 12, 13, 15).

3. Log in to the PostgreSQL shell. You need the superuser password (usually set during installation).

   .\psql -U postgres
   

   If you don't know the postgres user password, you may need to edit the pg_hba.conf file to set the method to trust temporarily, but try the password first.

4. List and Connect to the uzERP Database. Once inside the postgres=# shell:

   \l
   

   (Look for a database named uzerp, uzerp_live, or similar).

   \c uzerp_database_name
   

Phase 2: Identify the Table and Encryption

1. Find the Users table.

   \dt
   

   Look for users, system_users, or app_users.

2. Check the password column format.

   \d users
   

   Look at the column type for the password field (e.g., password, password_hash, pass):

   • If it is character varying(32), it likely uses MD5.
   • If it is character varying(60) or 255, it likely uses Bcrypt (standard for PHP apps).

Phase 3: Generate a New Hash & Reset

Since uzERP is PHP-based, it almost certainly uses the password_hash() function. You cannot simply type plain text into the database; you must insert a hash.

Option A: Generate a Hash using PHP (Recommended) Since uzERP is running on this server, you likely have PHP installed. Open a new command prompt window and run:

php -r "echo password_hash('NewPassword123', PASSWORD_DEFAULT);"

Copy the output string (it will start with $2y$...).

Option B: Use a Known MD5 (Legacy Systems Only) If the column is only 32 characters long, it uses MD5. The MD5 hash for "password" is: 5f4dcc3b5aa765d61d8327deb882cf99

Option C: Use a pre-calculated Bcrypt Hash If you cannot run PHP, use this hash which corresponds to the password password: $2y$10$C.qK/j5X8.y5.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X (Example only-use Option A for reliability).

Phase 4: Execute the Reset

Back in your psql window, run the update. (Replace users and password with your actual table/column names).

UPDATE users
SET password = '$2y$10$YourGeneratedHashStringHere...'
WHERE username = 'admin';

Verify the change:

SELECT username, password FROM users WHERE username = 'admin';

Troubleshooting: "I can't login to psql"

If you are locked out of the postgres database account itself on Windows:

1. Go to C:\Program Files\PostgreSQL\<version>\data.
2. Open pg_hba.conf in Notepad (Run as Admin).
3. Scroll to the bottom and change md5 or scram-sha-256 to trust for the IPv4 local connection (127.0.0.1/32).
4. Restart the "PostgreSQL" service in Windows Services (services.msc).
5. Run psql -U postgres again (it will not ask for a password).
6. Important: Revert this setting after you are done to maintain security.

... PostgreSQL Password Reset Tutorial ...

This video walks through the exact steps of editing the pg_hba.conf file on Windows to regain access to a PostgreSQL database if you are locked out of the root account.

Since you don't have a login for the Linux server itself, you need to gain physical (or virtual console) access to reset the root password first. This is a standard system administration task known as "booting into single-user mode."

Here is the step-by-step "break-in" procedure to get root access, then pivot to the database to reset your uzERP admin password.

Phase 1: The Linux "Break-In" (Reset Root Password)

You need to be at the physical keyboard or have the VM console window open (e.g., vSphere, Hyper-V, Proxmox). SSH will not work for this.

1. Reboot the Server.
2. Catch the GRUB Menu:
   • As soon as it starts booting, hold Shift (or press Esc repeatedly) to force the GRUB boot menu to appear.
3. Edit the Boot Parameters:
   • Use the arrow keys to highlight the default option (usually the top one, e.g., Ubuntu or Debian GNU/Linux).
   • Press e to edit the commands.
4. Modify the Linux Line:
   • Find the line that starts with linux (or linux16). It usually ends with ro quiet splash or similar.
   • Change ro (read-only) to rw (read-write).
   • Add init=/bin/bash to the very end of that line.
   • The line should look something like: linux ... rw init=/bin/bash
5. Boot:
   • Press Ctrl + X or F10 to boot with these settings.
6. Reset the Root Password:
   • You will drop into a root shell prompt root@(none):/#.
   • Type:

     passwd root
     

   • Enter your new root password twice.
7. Reboot Properly:
   • Type:

     exec /sbin/init
     

   • (Or force a hard reset if that hangs).

Phase 2: Pivot to the Database

Now that you can log in to the Linux OS as root, you effectively own the database user postgres as well.

1. Login as Root (using the password you just set).
2. Switch to the Postgres System User:

   su - postgres
   

3. Access the Database Shell:

   psql
   

   (If this asks for a password, your pg_hba.conf is strict. Since you are root, you can edit /etc/postgresql/12/main/pg_hba.conf (path varies), change md5 to trust for local users, and restart postgres. But usually, su - postgres gets you in without a password).

Phase 3: Reset uzERP Admin

Now you are back in the SQL interface.

1. Connect to the uzERP database:

   \c uzerp
   

   (If uzerp isn't the name, list them with \l).

2. Generate a new Hash (Using PHP): Open a separate terminal window (or exit psql temporarily with \q), and run this to generate a valid hash for "password123":

   php -r "echo password_hash('password123', PASSWORD_DEFAULT);"
   

   Copy the output string (starts with $2y$...).

3. Update the Admin Record: Back in psql:

   UPDATE users
   SET user_pass = '$2y$10$YOUR_COPIED_HASH_STRING'
   WHERE user_name = 'admin';
   

4. Exit:

   \q
   exit
   

Phase 4: Verification

Go to http://<server-ip>/uzerp and log in with:

• User: admin
• Password: password123

Next Step: If you get stuck on the "Break-In" phase (Step 4), tell me what text you see on the screen-some servers use LVM or encrypted disks which require one extra step to mount the drive.

You are nearly there! The error column "user_name" does not exist means we guessed the column name wrong, but the database gave us a hint at the bottom:

HINT: Perhaps you meant to reference the column "users.username".

This tells us the correct column is username. Since user_name was wrong, the password column is likely named password instead of user_pass.

The Correct Command

Try this command, which uses username and password:

psql -d uzerp -c "UPDATE users SET password = '$(php -r "echo password_hash('password123', PASSWORD_DEFAULT);")' WHERE username = 'admin';"

If that gives an error about the "password" column:

If it says column "password" does not exist, we need to see the exact column names. Run this short command to list them:

psql -d uzerp -c "\d users"

• Look for the column that stores the password (e.g., user_pass, passwd, password_hash) and use that name in the UPDATE command.