@@ -6,75 +6,31 @@ A lot of linked keys remain in the database, and this leads to keyspace pollutio
66For better data handling and clean database structure, I introduce some changes in service logic:
77
88## 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 )
1411
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 .
1916
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
2718When 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 ` .
3219
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.
3721
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 ` .
5024
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 .
5630
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.
6935
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
8036
0 commit comments