Jacques,
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.
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.
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.
Does this make any sense? Let me know if I am just confusing you more
and I'll try again.
Andrew
On May 2, 2009, at 1:25 PM, Jacques Le Roux wrote:
From: "Andrew Zeneski" <andrew.zene...@hotwaxmedia.com>
...snip...
The new authz implementation handles all of this for us. First we
define the permissions, access:example, update:example and
delete:example as seed data. These are also attached to the
example admin user's security group.
We will give all users access:example permission so they can
access the application, but only give admins the update and delete
permissions.
...snip...
Andrew,
I'm stil thinking at my question about read and access differences.
Why are you using access above, and in which cases read would be
used ? I have the feeling that we don't need access (or read maybe)
Here is a link to your answer http://docs.ofbiz.org/display/~jaz/
OFBiz+Security+Refactor#comment-7705 and the
difference it's still not totally clear to me. Is *read for
services* and *access for UI only* ?
Jacques
PS : Ha, I did not had a look at the example component yet, I better
understand now, acces looks like the old OFBTOOLS... But could you
please explain more how read will be used ?
