please add a hook in get_default_access()

[coldtrick]

Why do we want this?
Currently the system is user default access or site default access.

But if we want to allow a group to have a default access there is no way to manage this (except if we overrule the view input/access).

If a hook was fired in get_default_access() we (plugin developers) could fix this shortcoming ;)

If the hook was present we could for example fix #4333

[mrclay]

The input/access view (where get_default_access) is used generally doesn't have enough useful context info to pass to a hook. Also most tools set a access_id value for new content forms, so the return of get_default_access() would be overridden anyway.

I think plugins need to take responsibility for passing in useful context info (e.g. the container object, what object/subtype is going to be created, what kind of access: read/write/?) into a new API function like "elgg_get_access_for_new_entity", which would trigger the hook. The plugin would then pass this function's return value to input/access.

If plugins don't give us the context, then we have to do nasty things like sniff through debug_backtrace() to figure that stuff out. I'm already doing this in an input/access view I wrote for 1.6 and it's awful.

There's also the issue of the default options for an access control. Plugins should get a chance to alter this list as well, which is making me think a general purpose ElggAccess object should be used to encapsulate this mess instead of passing around access_id values and options_values arrays.

[coldtrick]

Replying to mrclay:

I think plugins need to take responsibility for passing in useful context info (e.g. the container object, what object/subtype is going to be created, what kind of access: read/write/?) into a new API function like "elgg_get_access_for_new_entity", which would trigger the hook. The plugin would then pass this function's return value to input/access.

This would require alot of plugins to be rewriten, maybe it should be done, but i'm looking for an easier fix.

If plugins don't give us the context, then we have to do nasty things like sniff through debug_backtrace() to figure that stuff out. I'm already doing this in an input/access view I wrote for 1.6 and it's awful.

The easiest way to make some sense of what the default access should be is with elgg_get_context() and elgg_get_page_owner_entity()

There's also the issue of the default options for an access control. Plugins should get a chance to alter this list as well, which is making me think a general purpose ElggAccess object should be used to encapsulate this mess instead of passing around access_id values and options_values arrays.

Plugins CAN change the access list use the hook "access:collections:write" for "user" or "all" (if you also wish to have the groups.

[mrclay]

Replying to coldtrick:

elgg_get_context() and elgg_get_page_owner_entity()

Forgot about those. So simply adding the hook could get us most of the way there. It also provides an immediate workaround by overriding the input/access view and manually triggering a hook on get_default_access's return value. What should the hook be named?

[ewinslow]

If you submit a pull request, we can hash this out and get this in for 1.9

[coldtrick]

patch supplied in ​https://github.com/Elgg/Elgg/pull/253

[cash]

Fixes #4415 adds default, access plugin hook - from Jerome

Changeset: 064251d5cc6a9cadcbd4183fd83cc57b6fd7641c