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
