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.
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.
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.
