ToDo
- Jim Wilson to document what tests may be impacted by this project and report to Accedia
- Jim Wilson to update this requirements document based on discussions in the 2022-11-22 status meeting.
...
Business Context→ BIE↓ | Human Resources | Agriculture | Construction | Entertainment | Notes |
|---|---|---|---|---|---|
ProcessPurchaseOrder (instance #1) |
| ||||
ProcessPurchaseOrder (instance #2) |
| ||||
NotifyShipment (instance #1) |
|
| |||
NotifyWIPStatus (instance #1) |
| ||||
NotifyWIPStatus (instance #2) |
|
Users - Roles
Tenant/Score role/tenant→role→ User↓ | HR Open Standards | ACME Brick | AgGateway | End User | Developer | Admin+Developer | Notes |
|---|---|---|---|---|---|---|---|
Bob |
| ||||||
Mary |
|
| |||||
Amy |
| ||||||
Roy |
|
| |||||
Matt |
| ||||||
Tess |
| ||||||
Ross |
|
|
|
Business Contexts - Roles
Tenant/Score role/tenant→role→ Business Context↓ | HR Open Standards | ACME Brick | AgGateway | End User | Developer | Admin+Developer | Notes |
|---|---|---|---|---|---|---|---|
Human Resources |
| ||||||
Agriculture |
| ||||||
Construction |
| ||||||
Entertainment |
...
Are all other user roles that are not Developer, Admin Developer, End User, and Admin End User considered subclasses of End User role? In other words, users in these roles inherit behavior of End User, e.g., they cannot create account, they cannot manage developer CCs, they can extend BIEs.
Note that if they can extend BIEs, it means that we have to also implement access logic on the CC side where they can manage only end user CCs. However, end user CCs have no BC assigned, so how to we infer access authorization? <serm>I couldn’t think of a nice and simple solution to this. The simplest thing to do, which sounds like a hack, is to do not allow BIE extension for users that are not End User or Admin End User. Another option is to inferred, roles associated with CCs from BIEs they are used in, but some EUCCs may not yet be used in any BIEs. Or we can say that if they are not used yet then only the owner can access it. </serm>. EUCCs logic also have to change in that only EUCCs with the same access authorizations can be used together, but what if the access authorizations change later on. This is getting pretty real complicated.
It looks like more sophisticated user role management functionality will need to be implemented in Score. For example, currently a user account cannot have multiple roles, e.g., an account cannot be both Developer and End User. We will still have to implement a user role management logic to do not allow the user account to have these two roles. Or that the user must select a role when he logs in, i.e., he cannot hold multiple roles when logging in. Also I think whether a CC or BIE is a Developer CC/BIE or End User CC/BIE, is inferred from the owner user. If the user can have multiple roles during the session, this logic can be affected.
...