ACL + adding rules/assets

Bluefox wrote: It can be that you have a lot of events with permissions set but that at a given moment you don't want to deny permissions for 1 group. You can alter all the events but a global option is maybe better,

Simply never do that. In fact, attaching permissions to single events should be an absolute exception. One should always create a good category structure and add permissions to categories.

The thing with the views I don't understand. For my understanding assets are for objects, not for views.

they are indeed objects

No, not in that context. The permission to edit events for example is attached to events or it's categories, but never to a view. You may set the views (view) access level (which is a completely different story) and may restict the data it should show (e.g. events of a specific category) or how it should look - which is user-independent. But if a user can edit an event is only a thing between the user and the event. The view has simply to respect this, always.

it sound to me know that you know where you're talking about

so am looking forward of how it's going to be dealt with in JEM2
(it will then be incorporated in JEM3)

That's my a bit academic view.

But I don't plan to integrate full ACL support in JEM 2 (as sayed somewhere else). It's just to better support current things in JEM 2 (JEM groups, JEM settings, component's ACL) e.g. to show unpublished events to authors/editors/owner, consistent in all views. This also differs a bit from Joomla where the author can't edit own content as long as it's not published - not really logical.
The main problem is to replace all the copied code from the models/views by calls to central functions which check the permissions. This way it's more easy to adapt this by changing one file only. On the other side this tends to have not the best performance in all cases which makes it difficult to find a balance.