[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Erw-devel] Feedback on authorisation
From: |
erw-devel |
Subject: |
Re: [Erw-devel] Feedback on authorisation |
Date: |
Tue, 23 Sep 2003 09:28:43 +1000 |
On Tuesday 23 September 2003 00:51, you wrote:
> I'm working at completing 1.0. The main improvement is that now the user
> interface is sensitive to permissions, so, for instance, if you make a
> relationship editing element read-only, you just get the relationship
> list without Remove button, and the background is grey.
I can see two sides to this:
1. Making inputs & lists (enums/relationships) sensitive to form
customisation's readonly attribute
2. Making lists/relationship controls sensitive to the authorisation system.
ie. if a user doesn't have update permission on the related table then
there's no need for the Modify button, similarly for New Item, Delete. This
has the advantage of making forms simpler for users that are in say a data
entry group rather than a system administrator group, hence dont need buttons
that they can't use.
The button(s) that aren't needed could be disabled or hidden, looks like your
preference is for hidden which is good.
> The situation is completely different for what matters embedded weak
> entities. In that case, the authorisation system is completely skipped,
> which does not happen with non-embedded weak entities.
>
> I'm changing the current setup so that for embedded weak entities
> authorisation IS necessary. Nothing is inferred from the main type. This
> seems to be right because updating, inserting or deleting an embedded
> entity is actually an entity-, not a relationship-based operation. This
> also aligns embedded and non-embedded entity types.
I haven't used embedded weak entities much, but can comment on non-embedded
weak entities.
Say there is an entity called 'parent' which has a weak entity called
'child', which in turn has a weak entity called 'toy'. If a user has update
permission on parent they would also need to be configured with update
permission on child and on toy.
Similarly if the entity type parent has owner=true & hence uses row
authorisation then child would also need owner=true, and it's weak entity toy
would also need owner=true. This also simplifies querying on weak entities,
you dont need to join toy with child and with parent to find out which owner
and group it belongs to because toy would have that information. As you say
the use of a weak entity is actually inserting/modifying/deleting an actual
entity so it needs it's own authorisation.
Ciao,
Jason.