Hi Andrew,
Thanks for your answer and your time on this important subject that should
benefit to all the community!
I had not much time these last days to follow, and I'm still have to read some
messages (notably the couple of threads David opened
lastly).
Thanks to everybody's explanations, my understanding is really better now.
So from you explanation below I understand that, as I supposed at the
beginning, it's a kind of OFBTOOLS.
Not exactly since you need to have OFBTOOLS to gain access to a component while
you don't need to have access. On the other hand if
you have access you have access to this component.
Though at this time I did not have a very good understanding (and I'm sure I
still miss some points, but hopefully not about access
;o), I have discussed about access a bit with a client.
Of course everybody using the ERP side of OFBiz is *very interested* by access
auth. and by all possible improvments of this central
feature.
He gave me an idea, while we were discussing about possible reason of the
access introduction.
As he knew even less than me his interpretation was not right (I was already
able to explain why) but his conclusion is interesting.
He suggested that this may be used to grant all other rights (CRUD ones). So it
would allow to quicly set all other permissions
What do you think about such a possibility ? A kind of ADMIN stuff. We could call it
"All".
Also he wondered why we would differentiate create from update. I gave him some
examples (like an automatic task able to create but
not to change) but he was not very convinced.
I then said that this is used by Unix file systems too. It's subjective but
when you refer to Unix/Linux file systems it helps
people to "understand".
Afterward I thought that maybe we could also have a look at how access control
is managed there. After all files are kind of
artifacts, and Linux files systems are known as efficient...
Of course the problematic for files access is far less complex and I don't say
it's a paradigm, but we may find some ideas (if we
need ones at some point).
For instance, it's pretty clear that all files store their own permissions and
all have a combination of them. But I feel anyway
that this is a bit out of topic :/
Though Adrian is drawing his proposal by looking at Novel Netware, IRRW.
Jacques
From: "Andrew Zeneski" <andrew.zene...@hotwaxmedia.com>
Jacques,
Thanks for your questions. I will address each one inline...
Honestly, in my initial plan I only had 4 permissions create,read,update and
delete. Then after thinking about it, access
seemed
to be a nice extra permission to limit access to applications. Read is
nothing more than what view is today, the only reason
for
using the name "read" instead of "view" is because we can call them CRUD
permissions or ACRUD permissions if we keep access.
Yes I see, we need something like OFBTOOLS was used for.
But can't we use simply read for that. It seems to me that access introduce
redudancy.
What would be the differences between, for instance
access:sfa vs read:sfa
access:sfa:lead vs read:sfa:lead
access:sfa:opportunity vs read:sfa:opportunity
etc.
access:sfa would mean that the user can simply access the application. Where
read:sfa would mean, the user can read anything in
the SFA application. A better example of this would be the order manager,
where access:order would allow the user to login, but
read:order would allow the user to view any order/request/etc in the
application. A more granular permission of
read:order:orderdetail:10000 would limit the user to only reading the specific
order without granting permission to the rest of
orders/requests/etc.
I would not recommend creating granular permissions for access, unless we wanted to
limit the access of specific "tabs" or areas
in an application. If we wanted to restrict access to leads in sfa, then we
might create an access:sfa:lead process/permission
which can then be used to restrict access to the leads section of the app.
Where as read:sfa:lead would mean the user can view
any lead.
So, access was added only for granting access to the application. In most
cases this is the only permission a user would need
to
access an app. Let's use Project Manger as an example for this:
access:project would be the permission required to access the application.
All users of the app would have this permission.
The
create:project permission would be given to a administrator, so new projects
could be created same with create:project:task.
However, create:project:task would have some dynamic access logic associated
which would allow users to create tasks as long
as
they were associated with a project in certain role(s). The read:project
permission could be used to restrict viewing
details
of a project, task, etc.
But could we not use read:project instead of access:project, and then keep
only the CRUD permissions ?
What we will be missing if we remove access ?
I don't think so. Because read:project would grant the user global read access
to all projects. Instead, when displaying a
project we might want to attach the process of read:project:10000 to the UI,
to verify the user is indeed allow to read that
project. Where access:project would just simply allow the user to login to the
tool.
This is just how I have been thinking of it, read could also be used in
replace of access, I just thought it would be more
flexible to have the extra permission. Mainly because I believe that most
users only need a permission to access the
application, the other permissions would be handled in a dynamic way based on
how the user is associated in the application.
Could you please elaborate on the extra permission and why it's needed ?
I think I elaborated in the above two comments, so if this is still vague
please let me know and I will try to explain it again
in a different way.
Thanks again for your questions!
Andrew
