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.