On May 5, 2009, at 4:57 PM, Andrew Zeneski wrote:
On May 5, 2009, at 5:24 PM, David E Jones wrote:
Well, this is starting to sound exactly like what I proposed, with
the exception that in my proposal everything would be tied to a
"process" rather than an artifact. The process of "updating a
party record" is attached to the artifacts which are involved in
the process, then permission logic is attached (by database
configuration) to that very same process.
I'm not sure what you mean by this... which proposal are you
referring to?
If it is the main one you documented and implemented I think there
are some big differences here, mainly that the artifacts themselves
do not have anything in them for configuring access control
(permissions, etc), not even specifying a "process" that they are
part of, and instead the external stuff where access control is
configured refers to the artifacts.
Yes, the same proposal I have been talking about from the beginning.
While you are correct that the current implementation and proposal
does not have a specific method of "registering" artifacts with the
process, instead it is using the current patterns to check access to
for the process within the artifact. In the end, this is all exactly
the same thing, registering an artifact and adding authorization
logic to the artifact's framework or calling the same functionality
from within the artifact is all really just a matter of aesthetics.
So, this is something which could be added to any system which is
developed.
Yeah, they can both serve the same purpose. What I'm thinking is that
for end users it will be a lot easier to go through a UI and change
something in the database than it will be to change the XML files for
the applications. This means it will also be possible to do general
reconfiguration without any redeployment.
To me a process driven model is far more comprehendible to an
average application administrator, where an artifact based would
be way more technical. An administrator would need to understand
all the artifacts in the application in order to configure things
properly. Where in a process model, the admin only needs to
understand the process involved and the artifacts are associated
to the process during development.
Defining the processes involved in an application is something
which should be done during design. During implementation, all
that needs to be addressed is associating the artifacts to the
correct process.
In my opinion security should be thought of as a business level
requirement, putting it on the artifact is too technical.
Screens and forms are very much business level artifacts in my
opinion, and it does seem like for the most part when people ask
about configuring access control they have specific screens, forms,
form fields, etc in mind.
I agree that a rendered screen or form is a business level artifact,
but a screen definition or form definition is no more a business
level artifact than a Java class, XML file or JSP would be. These
are very technical artifacts IMO.
I think I see what you mean... like from an end-user perspective. That
is basically what I have in mind with my comment above.
On a side note, usually when I say "business-level artifact" I mean in
contrast to framework-level artifacts, so a business-level artifact
would be anything in the ofbiz/applications or ofbiz/specialpurpose
directories, or perhaps better put anything that is not in the ofbiz/
framework directory. Whatever tool is used to write it, it is business
logic (or business presentation or whatever) as opposed to purely
technical enablement.
As for a process... what is that anyway (I mean on a conceptual
level, putting it in terms that should be understandable by someone
not familiar with what you're working on, and not even familiar
with OFBiz)? Is it a way of grouping screens or other artifacts? If
so, that's fine, in fact that's great, and it's one of many ways of
grouping artifacts to help deal with the fact that at that level of
granularity there are a lot of options to deal with (people usually
ask for it before realizing how many options there really are).
I gave an example of a process at the top of my message. Another
example would be "update a party's email address". In this process
there is a service (usually one, but not always) a screen, a form,
some fields, etc. In the current authz implementation these
artifacts would call their respected methods of checking access to
that process, however as I mentioned above this could easily be
changed to be part of the artifact's framework, so that an artifact
would then register itself with the process. Again, this really
won't effectively be much different than calling the existing has-
permission method(s).
So, while yes I guess it is a way of grouping artifacts, I never
considered it as such. I've always thought of it simply as the
artifacts are all used in a specific process (or processes).
Anyway, to explore the "process" concept further in general a
single artifact (such as a screen) is typically used in more than
one business process. All that means is that a single artifact can
be a member of more than one artifact group and if the user has
access to any of those artifact groups they have access to that
screen.
On the other hand, if that is too liberal (which it seems to me, ie
it might allow access where it isn't intended) then we may need to
restrict it more. What I mean by that is the term "process" to me
might mean that they can use a certain screen (or other artifact)
as part of that process, but not as part of any other process or
for any other reason. If that's the case then we need something
else in the project to keep track of which "process" the user is
currently in... and that would be kind of like the Seam
"conversation" scope.
This may be something to consider, and very much like how the auto-
grant functionality works in the prototype I committed, once a user
is granted permission to a specific process, permissions to other
processes are granted for the duration of that request. This is so
when a user is granted permission to update a lead in the SFA
application, the user is also granted permission to update the party
record for that lead. This is all scoped for just the duration of
the request.
What I'm leaning towards above would be kind of like the auto-grant
stuff if there was one permission for each artifact. The idea is to
default to the level of full granularity (each artifact's name being
the permission) and then make sure we have tools and conventions to
make it easy (and even possible!) to deal with them.
-David
