--- On Fri, 5/1/09, Andrew Zeneski <andrew.zene...@hotwaxmedia.com> wrote:
> What changed is that now the permission logic is NOT tied
> directly to the service itself. The logic is tied to the
> permission. So ANY call to authz.hasPermission() the EXACT
> same code runs that checks the permission. That is the
> single point of contact, the hasPermission() method.
>
> The checks in the screen definition runs the same code as
> the checks in service definition. So now one advantage is,
> the update or delete button which is displayed in the UI if
> the user has permission will display (even if they do not
> have the static permission associated with their account) if
> the user can edit that specific item. It won't display
> for other items which the user cannot modify.
I must be missing something. Still using the Example component as an example:
the service definition called a service permission, which called a script,
which ultimately called Security.hasPermission. Your modification has the
service definition use the <required-permissions> which ultimately calls
authz.hasPermission(). So, both methods end up calling a single hasPermission()
method. What changed?
The only difference I see is that the permission string moved from a script to
the service definition. Is that the desired benefit?
> >> 3. Avoid having to check multiple permissions, for
> example
> >> PARTYMGR_UPDATE or PARTYMGR_ADMIN. Instead we use
> a new
> >> permission format which embeds all permissions
> which will be
> >> accepted:
> >
> > I don't see that being done explicitly in our
> current code. The OFBizSecurity class does that
> automatically. Any permission check is done with the ADMIN
> permission first, then the requested permission.
>
> Okay, so that was a bad example. How about CATALOG_UPDATE
> or CATALOG_ROLE_UPDATE instead as an example. Instead a
> simple permission defined as update:catalog:${catalogId}
> would take care of both of these. If the user has the static
> 'update:catalog' permission it would be granted
> (like a catalog admin might have), otherwise it would run
> the DA logic to determine if the user has permission to
> update that specific catalog.
The idea of specifying some kind of parameter in the permission is interesting.
The question is, (speaking as a user) What does that parameter do?
> >> 4. Define permission for users, not admins.
> Instead of
> >> looking for a static permission, set the
> permission to be
> >> checked at the most granular level. When doing so,
> admin
> >> users will always have permission and the API will
> handle
> >> user access using DA logic.
> >
> > I disagree. I might want my application to behave
> differently if an admin is using it. Without an admin
> permission (or attribute), how will I know if a user is in
> an admin role?
>
> Then we will create an 'admin' base permission. I
> didn't see the need for it, b/c I can't think of
> anything in which I would say "don't show this to
> people who can access/create/read/update/delete; only show
> it to an admin". I have nothing against this, just
> couldn't think of any really useful cases. Do you have
> something specific in mind?
Maybe that could be expressed as :component:admin.
-Adrian
