@@ -6,75 +6,31 @@ A lot of linked keys remain in the database, and this leads to keyspace pollutio
6
6
For better data handling and clean database structure, I introduce some changes in service logic:
7
7
8
8
## General defs
9
- - ` inactive-users `
10
- Redis database sorted set key. Assigned to ` USER_ACTIVATE ` constant.
11
- Record contains ` userId ` as value and ` timestamp ` as score.
12
- - ` user-audiences ` [ Described here] ( update_metadata_lua.md#audience-list-update )
13
- - ` deleteInactivatedUsers ` Redis script, handling all cleanup logic.
9
+ - ` inactive-users ` [ Described here] ( #inactive-users-index )
10
+ - ` user-audiences ` [ Described here] ( user_and_organization_meta_update.md )
14
11
15
- ## Organization Members
16
- The ` organization add member ` process doesn't have validation whether the user passed activation and allows
17
- inviting inactive users into an organization. The script checks whether inactivated user assigned to any organization
18
- and deletes users from organization members and user->organization bindings .
12
+ ## ` inactive-users ` index
13
+ It's an Additional Redis Sorted Set which contains the list of IDs of the ` inactive ` users.
14
+ Each item score is equal to the ` timestamp ` set on user creation.
15
+ To avoid hardcoded SET name new ` USERS_INACTIVATED ` constant introduced .
19
16
20
- ## Registration and activation
21
- Every Activation and Registration request event executes ` users:cleanup ` hook.
22
- The Activation request executes the hook first this strategy saves from inactive
23
- users that hit TTL but tried to pass the activation process.
24
- The Registration request executes the hook after ` username ` exists check.
25
-
26
- ## Registration process
17
+ #### Registration process
27
18
When the user succeeds registration but activation not requested, the new entry added to ` inactive-users ` .
28
- Record contains ` userId ` and ` current timestamp ` .
29
-
30
- ## Activation process
31
- When the user succeeds activation ` userId ` ,the entry deleted from ` inactive-users ` .
32
19
33
- ## ` users:cleanup ` hook ` cleanUsers(suppress?) `
34
- ` suppress ` parameter defines function error behavior. If parameter set, the function throws errors,
35
- otherwise, function calls ` log.error ` with ` error.message ` as message.
36
- Default value is ` true ` . IMHO User shouldn't know about our problems.
20
+ ** NOTE:** Old Redis ` expire ` setting methods left in their place, to save old service behavior.
37
21
38
- Other option, is to define new config parameter as object and move ` config.deleteInactiveAccounts ` into it:
39
- ``` javascript
40
- const conf = {
41
- deleteInactiveUsers: {
42
- ttl: seconds, // replaces deleteInactiveAccounts
43
- suppressErrors: true || false ,
44
- },
45
- }
46
- ```
47
- Calls ` deleteInactivatedUsers ` script with TTL parameter from ` service.config.deleteInactiveAccounts ` .
48
- When script finished, calls TokenManager to delete Action tokens(` USER_ACTION_* ` , ``).
49
- * NOTE* : Should we update TokenManager to add support of pipeline?
22
+ #### Activation process
23
+ When the user succeeds activation the entry deleted from ` inactive-users ` .
50
24
51
- ## Redis Delete Inactive User Script
52
- When the service connects to the Redis server and fires event "plugin:connect:$redisType" ` utils/inactive/defineCommand.js ` executed .
53
- Function rendering ` deleteInactivatedUsers.lua.hbs ` and evals resulting script into IORedis .
54
- The Script using a dozen constants, keys, and templates, so all these values rendered inside of the template using template context .
55
- Returns list of deleted users .
25
+ #### Index cleanup
26
+ On ` registration ` cleanup method executes before user creation .
27
+ On ` activation ` cleanup method executes before any checks performed by ` activation ` action .
28
+ * Uses ` dlock ` for itself to be sure that only one process runs .
29
+ * Gets outdated user list and deletes them .
56
30
57
- * NOTE* : Using experimental ` fs.promises.readFile ` API function. On ` node ` 10.x it's an experimental feature,
58
- on ` node ` >= 11.x function becomes stable without any changes in API.
59
-
60
- #### deleteInactivatedUsers ` USERS_ACTIVATED ` ` TTL ` as seconds
61
- ##### Script paramerters:
62
- 1 . KEYS[ 1] Sorted Set name containing the list of users that didn't pass activation.
63
- 2 . ARGS[ 1] TTL in seconds.
64
-
65
- ##### When started:
66
- 1 . Gets UserId's from ZSET ` USERS_ACTIVATED ` where score < ` now() - TTL * 1000 ` and iterates over them.
67
- 2 . Gets dependent userData such as username, alias, and SSO provider information used in delete procedure and calls [ Delete process] ( #delete-process ) .
68
- 3 . Deletes processed user ids from ` USER_ACTIVATED ` key.
31
+ ## TODO Organization Members Need additional information
32
+ The ` organization add member ` process doesn't have validation whether the user passed activation and allows
33
+ inviting inactive users into an organization. The script checks whether inactivated user assigned to any organization
34
+ and deletes users from organization members and user->organization bindings.
69
35
70
- ##### Delete process
71
- The main logic is based on ` actions/removeUsers.js ` .
72
- Using the username, id, alias and SSO providers fields, script checks and removes dependent data from the database:
73
- * Alias to id binding.
74
- * Username to id binding.
75
- * All assigned metadata. Key names rendered from the template and ` user-audiences ` .
76
- * SSO provider to id binding. Using ` SSO_PROVIDERS ` items as the field name decodes and extracts UID's from Internal data.
77
- * User tokens.
78
- * Private and public id indexes
79
- * Links and data used in Organization assignment
80
36
0 commit comments