Skip to content

Commit eeeb9a2

Browse files
authored
add upgrade instructions for users table (#122)
1 parent 5e1d0ea commit eeeb9a2

File tree

1 file changed

+87
-0
lines changed

1 file changed

+87
-0
lines changed

docs/admin-manual/upgrade-instructions.md

Lines changed: 87 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -13,3 +13,90 @@ When migration from `3.5.2` to `3.5.3` make sure that you don't have in database
1313
Though it was possible before 3.5.3 under certain circumstances to create users with either one or both of these two columns set to NULL, it is very unlikely that this case is relevant for you.
1414
In case you have some - please delete these entries (`DELETE users WHERE home_folder_id IS NULL OR inbox_folder_id IS NULL`)
1515
No worries about deleting user entity with NULL value for `home_folder_id` or `home_folder_id` as such entities are stale anyway - they have no documents associated and no login is possible.
16+
17+
18+
## 3.6 (not yet released)
19+
20+
Here’s a clean version of the migration note you wrote, with steps clearly structured for admins who need to ensure `users.created_by` and `users.updated_by` are populated correctly:
21+
22+
---
23+
24+
### Audit Feature Migration (v3.6)
25+
26+
Starting with **version 3.6**, Papermerge introduces the **Audit feature**, which records *who did what and when*.
27+
This affects almost all database tables, which now include audit columns:
28+
29+
* `created_at`
30+
* `created_by`
31+
* `updated_at`
32+
* `updated_by`
33+
34+
There are couple more, but they are irrelevant here.
35+
The most critical change:
36+
37+
👉 The `users` table **must have non-empty values for `created_by` and `updated_by`.**
38+
39+
---
40+
41+
#### How to Fix Existing `users` Rows
42+
43+
If you are upgrading, you must manually update `users.created_by` and `users.updated_by` to valid user IDs (for example, your administrator user).
44+
45+
⚠️ **Important:** You must **disable** the trigger `set_created_by_updated_by_trigger_users` before updating, otherwise the update will not work.
46+
47+
---
48+
49+
#### Step 1: Find your admin’s user ID
50+
51+
```sql
52+
SELECT id, username, updated_by, created_by FROM users;
53+
54+
-- Example output:
55+
-- 49e78737-7c6e-410f-ae27-315b04bdec69 | admin | <empty> | <empty>
56+
```
57+
58+
Copy your admin user’s `id`.
59+
60+
---
61+
62+
#### Step 2: Disable the trigger
63+
64+
```sql
65+
ALTER TABLE users DISABLE TRIGGER set_created_by_updated_by_trigger_users;
66+
```
67+
68+
---
69+
70+
#### Step 3: Update all users
71+
72+
```sql
73+
UPDATE users
74+
SET updated_by='49e78737-7c6e-410f-ae27-315b04bdec69',
75+
created_by='49e78737-7c6e-410f-ae27-315b04bdec69';
76+
```
77+
78+
---
79+
80+
#### Step 4: Verify the update
81+
82+
```sql
83+
SELECT id, username, updated_by, created_by FROM users;
84+
85+
-- Example output:
86+
-- 49e78737-7c6e-410f-ae27-315b04bdec69 | admin | 49e78737-7c6e-410f-ae27-315b04bdec69 | 49e78737-7c6e-410f-ae27-315b04bdec69
87+
```
88+
89+
---
90+
91+
#### Step 5: Re-enable the trigger
92+
93+
```sql
94+
ALTER TABLE users ENABLE TRIGGER set_created_by_updated_by_trigger_users;
95+
```
96+
97+
---
98+
99+
✅ Now all `users.created_by` and `users.updated_by` fields are properly set, and the audit system will function correctly.
100+
101+
---
102+

0 commit comments

Comments
 (0)