I should also note that in the process based system I have been
talking about we can easily follow similar patterns Adrian has
recommended. Service artifacts are one thing, as they usually only
relate to a single process. But in screens and other artifacts we
could "register" them with a process:
<screen ...>
<security process="party:contact" check="update/>
</screen>
This would populate a list of permissions available to the current
user for the process within that artifact and require the user to be
able to update in order for the screen to render. Then if we were
displaying a delete button another check could be run <security
check="delete"> to see if the delete button should be rendered.
This is technically no different than doing has-permission checks,
just doing so in a different XML format and instead of calling has-
permission many times it just gathers all permissions at once and then
permission checking is just handled from the screen's context.
I never even considered such a thing when I started working on the
process based designs because I was taking ease of migration into
consideration. Changing from plain permission checks to a more process
based permission string was large enough. However, my point is that if
we are considering ways to change all the artifacts in OFBiz and how
they deal with security it can be done with either of the two
proposals. With the process based designs it could just be done at a
later time.
Andrew
On May 5, 2009, at 2:04 PM, Andrew Zeneski wrote:
Adrian,
While this is fine when a artifact handles a specific "process" but
what about when a screen (for example) like EditExample would be
used for different processes? Often the same screen/form is used for
create vs update; and even more often a user will have access to
create but not update [everything].
Also, an artifact (such as a screen) could contain multiple
processes. A list screen for example may also include a delete
button. However, with no explicit permission checks, the delete
button will display for all users who have access to this artifact.
So, you would still need to have explicit permission checks to see
if the user has access to the delete button in this artifact.
Andrew
Permissions are hierarchical - each artifact inherits permissions
from the artifact above it. This is very similar to what Andrew is
trying to achieve, but it's different because the artifacts
themselves control the security - there is no call to a permission
service with a permission string.
Here's what it might look like in ExampleScreens.xml:
<screens xmlns:xsi="...">
<security domain="framework:example:screen"/>
<screen name="EditExample">
<security domain="EditExample"/>
...
</screen>
</screens>
Notice there are no explicit permission checks. Instead, each
artifact has identified itself in the security domain.
