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
RBAC
- RBAC actions are basically list of flows, with target coming from the flows base objType (using either that objTypes rbac additional 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