adds content_access_by_path module

[markconroy]

No description provided.

[finnlewis]

@joachim-n was asking today if "anything in the codebase using the node access API?".

Does hook_node_access count ?

If so, I'd like to understand the implications of including this in localgov_core.

Any initial thoughts @ekes @stephen-cox @andybroomfield ?

[joachim-n]

That's not part of the node access system, it's the entity API's hook_ENTITY_TYPE_access() for nodes.

What I meant was the old pre-D8 node grants system.

[stephen-cox]

We discussed the process of adding new modules to LGD at the tech governance meeting last Thursday and there was a proposal from a year ago with checklist for this here: https://docs.google.com/document/d/1OCs3W7WFGtDNpL0U-6lhT6pQpOf2RydjtpkAMOrUeI4/edit#heading=h.56kj0gjrk8s8.
Is this a good opportunity to run through the checks we outlined?

Also, is LGD Core the best place for this? The original idea was Core would contain shared functionality between modules and could (in theory) be installed in a non-LGD site (if someone just wanted Guides, for example). If this is still the case then this sort of thing should go in to the profile until we move to recipes.

[ekes]

I think stephen's comment is the correct approach

I have one further question that jumps to mind directly: Does this mean that we have to remove 'Create and edit URL aliases' from any roles? Does this module work if you do? But otherwise it's less access and more see link? Because /admin/config/search/path/edit/{path_alias} just checks that permission I think? Answer no. Because that permission does not actually grant entity access create and edit permissions, just the permission on the related entity form.

[andybroomfield]

Just to quick clarify (noting @stephen-cox point above). Is this actully enabling anything. I don't think modules should be required by localgov_core unless they are an actual dependancy. Suggested modules for the distribution I think belong with the localgov profile.

Is the intention to turn this on by default making it a canioncal way of having node access, or is it just an optional module?

To answer point above. BHCC uses both views_unpublished and VAPN which both use hook_node_access.

[markconroy]

Hi @andybroomfield

I think this is supposed to just be an optional module, not a default canonical way of doing access control.

I think with that being the case, it should be created against the profile rather than core, is that right?

[andybroomfield]

It would go in the profile, so should be made as a PR against localgov.

[markconroy]

@andybroomfield localgovdrupal/localgov#745