THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
If each artifact has its own set of permissions, there could be potentially thousands of permissions - an administration nightmare! It would be helpful to have artifact permissions organized in a hierarchy - so that permissions defined higher up in the hierarchy are inherited by artifacts lower in the hierarchy. The hierarchy will reduce the number of permissions needed.
| Note |
|---|
The following hierarchy has been called a "static hierarchy" and it is not finalized. There is an alternative to it called "dynamic hierarchy" - see below. |
The components in OFBiz are organized in a hierarchy, and each component typically contains entities, services, and screen widgets. We can build on that structure to set up a hierarchy of security-aware artifacts:
...
Note that parentAuthorizationState will never be set to "Deny" because before that would happen the auth would have failed and an error sent back up the stack.
| Note |
|---|
The following hierarchy has been called a "dynamic hierarchy" and it is not finalized. There is an alternative to it called "static hierarchy" - mentioned above. |
Example Chain:
- Component
- WebApp
- ControllerRequest
- ControllerRequestEvent
- Service
- Entity
- EntityField
- Entity
- Service
- ControllerRequestEvent
- ControllerView
- WidgetScreen
- Service
- Entity
- EntityField
- Entity
- FtlFile
- WidgetScreen
- WidgetForm
- WidgetFormField
- Service
- WidgetScreen
- ControllerRequest
- WebApp
...