>
> I am not sure that I understand your suggestion. If I am login with some
> user which is with fixed groups how this groups will be changed when I
> am on different objects?
What I'm suggesting is that you never change the groups. Instead, you
have a group for each specific situation. Now I understand that you're
talking about one application, not separate ones. So you could have a
large group users, and smaller groups cinema-manager, museum-manager, etc.
> Imagine that the application is looking like Windows Explorer where the
> left side is one Tree, and the right side is a table. You select an
> object cinema "Metropolitan" which extends Company where you are the
> boss. So, in this case you must to have "cinema-manager" group and
> rights. Then you select another cinema "Multiplex" where you are just
> user. In this case you must to have "cinema-user" group and rights. Both
> cinemas are children of parent Cinema which extends Company for example.
> The same with another type of objects like museums, warehouses, etc.
> How this will be realized with your suggestion?
Groups: users, metropolitan-manager, multiplex-manager, etc. A person
would be in the general user group and then also in whatever *-manager
group was appropriate. You can also have "higher level" groups such as
cinema-manager and the multiplex manager resources would only be able to
be accessed by users in groups multiplex-manager and cinema-manager.
With your idea of changing the group based on the user and resource
being accessed, you'd have to have some way to know which users have
access to what resource that didn't have anything to do with groups. In
my suggestion, the groups are finer grained and take care of all that
for you in the first place.
The dynamic idea scares me a little because you have to be very sure
there's not a way for a user to gain access s/he should not have. For
instance, principal P is only a user for resource R1 but is a manager
for resource R2. So, when accessing R2, if you change P to be in a
generic "manager" group, there could be some way for P to access R1 as a
manager if you're not careful. In a web application, for instance, this
would be as simple as accessing R2 and then pasting the R1 url into the
browser before doing any other action that would cause him to be removed
from the manager group. Your application sounds different, but I just
wanted to give an example of the worst case scenario.
Cheers,
Bobby