User Data Handling
Overview
submittedByUserId, targetUserId and targetIdentifiers for permissions/account limits/resource use, and for creating automatic data such as createdBy and belongTo relationships in graph database.
Structure
- baseUserId can stay in iz_Context because it should not change during processing
- maybe change baseUserId to submittedByUserId to be more clear, but see baseUserId reason for name below
- however consider if future flows will handle many submittedByUserIds, eg automated tasks that handle many submitted tasks, if that is common it might be better to allow generated code to pass the submittedByUserId as a flow input param
- targetId change to identifer object {fieldname: fieldValue} named targetIdentifiers
- generated code can where possible add this automatically when initializing flows, and can check received valid identifiers according to flowSchema
Graph
- automatically adds createdBy/versionData updatedBy relationships for objects created/updated by user
- automatically adds createdBy/updatedBy for relationships created/updated by user, relationshipSchema specifies which node to connect this history to
- automatically adds belongTo relationship when creating a node connecting to targetIdentifiers instance of belongTo objType
- relationshipSchema sets which side is belongTo node, that node must have belongTo relationship (ie that node must have belongTo or rbac addOnDataStructure)
RBAC
- RBAC actions are basically list of flows, with target coming from the flows base objType (using either that objTypes rbac addOnDataStructure or if that objType has belongTo following that)
- generated code automatically validates submittedByUserId and targetIdentifiers, sends to permissionHandler/RBAC
Account Limits
- standardize checking of accountLimits so generated code can check per flow
- probably allow for additional developer added accountLimits to be checked anywhere in code
Resource use
- ? connected to target user if belongTo = user, but if not connect to submittedByUserId