erw-devel
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]