[#71] API Doc conversion to a node type #84
Conversation
|
@arlina-espinoza @cnovak I have tested this on an existing install, and it works as expected.
Here are some anticipated changes on Kickstart profile
|
README.md
Outdated
| with views. To set up an RBAC, we recommend ["Permissions by term"](https://www.drupal.org/project/permissions_by_term), | ||
| which can cover the following scenarios: | ||
|
|
||
| - Restrict access on reading docs or creating apps: |
There was a problem hiding this comment.
We should minimize the details put here and instead link out to the Drupal.org docs we have for the module to make things easier to edit. We could put all of this on a page and then move the content. We also may want to put these overall concepts under Kickstart since they have to do with API Product lockdown and API Doc lockdown?
README.md
Outdated
| API product, but want to only allow certain developers to be able to use that API product so that we can add manual or | ||
| automatic steps before approving access. | ||
| To implement using "Permissions by term": | ||
| 1. Create a role for each teams of developers, and assign users accordingly. (The important step here is that the |
There was a problem hiding this comment.
These steps seem to be the same as the "Restrict access on reading docs or creating apps". For this situation I think we need to explain in more detail that you can skip step 2 and 3 if you want anyone to see the docs and that the API Product should be locked down using "API Product RBAC", or they can let anyone try to create an app but then use manual approval to let the developer use the API.
README.md
Outdated
| 3. On the API Doc node, tag it with the above term. | ||
|
|
||
| - Set access defaults for new API Products | ||
| As an API provider, I want to set the access control of a new API Product to be hidden for all users except |
There was a problem hiding this comment.
This seem to also be the same steps as the two use cases above, shouldn't it instead talk about how you can set a new taxonomy term as default in the API Doc content type so that when a new API Doc is created it would be automatically locked down to a certain role?
Co-authored-by: Chris Novak <[email protected]>
Co-authored-by: Chris Novak <[email protected]>
Co-authored-by: Chris Novak <[email protected]>
Co-authored-by: Chris Novak <[email protected]>
…edit node access check.
There was a problem hiding this comment.
LGTM, @arlina-espinoza to move docs about this to Drupal.org before merging.
Fixes #71. This PR provides the same functionality as 8.x-1.x, but it uses node type instead of a custom entity, making it possible to integrate seamlessly with views, as well as use the wide array of Drupal Contrib modules for node access control. It will also reduce the amount of code we maintain, as the base functionality is provided by core.
For now, it does not provide an upgrade path from the 1.x branch, only a fail-safe to throw an error if users try to update from 1.x - see #80 .
I've written some condensed instructions on setting up the Permissions by term module in the README, but I think they should be expanded on the drupal.org docs.