On Jun 15, 2009, at 4:39 AM, Jacopo Cappellato wrote:
On Jun 15, 2009, at 11:50 AM, David E Jones wrote:
If what I am proposing here makes sense, we can think about my
last proposal as an initial start toward this effort. We can
start with defining application specific security groups. So that
if someone has permissions only for a Order Manager application,
he won't be able to control other applications.
Isn't this the exact opposite of what you described above?
The reason I say that is that the base applications are organized
according to general business concepts that make up the way the
data is organized, and they have little to do with processes. In
fact, because the base application are organized this way most
business processes will actually need to go across the various base
applications.
This is a very good point David: each of these roles will have
permissions from different applications for sure. Where should we
place the demo/seed data? Maybe we could add the data in new files
in the ecommerce application.
The existing security groups are probably close to the definitions
of actors than a security group for each application would be.
Because of that I think that doing so would actually be a step
backwards, both in theory and in practicality.
I agree that we should start by looking at and reviewing the
existing process/role oriented groups and (demo) users:
https://demo.ofbiz.org/webtools/control/FindGeneric?entityName=UserLoginSecurityGroup&find=true&VIEW_SIZE=50&VIEW_INDEX=0
By reviewing I mean:
1) write short stories about the tasks allowed by each security
group (probably as comments in seed data)
2) verify that we have a userlogin for each of the security groups
(and create missing ones)
3) verify if a user associated to the user login is really able to
perform the tasks listed in #1; if not, adjust permissions
4) possibly add more roles/groups and demo users
Then when we will write new stories for ofbiz, or we will implement
new processes, we should always state for which demo users they are
intended for.
What do you think?
We don't really have requirements for the current applications and
security groups and permissions and such, and in fact these things
weren't created based on a certain set of requirements but instead
evolved over time.
I might be wrong, but I think it will be easier to start with
requirements and move forward than to start with the implementation
(ie OFBiz as it is now) and move backward. In other words, something
along the lines of what is described here:
http://docs.ofbiz.org/display/OFBREQDES/UBPL+Introduction
-David
