The module is working great, but this lack of functionality struck me as strange. I assume it just lacked a use case for the development until this point.
There are currently permissions for:
* allowing users to view unpublished entities
* allowing users to access the token overview page at /admin/content/access_token
* allowing users to delete AU tokens
* allowing users to renew AU tokens
Regarding the last 2 around AU tokens, they can delete and renew. The delete of the token can happen either from the /admin/content/access_token page or in the "Temporary unpublished access" section of the node edit sidebar. I'm not really sure where users can renew a token, I assume after a token expires, there is a new Renew option available if the user has permission.
But, what I think is missing is a permission to control the actual Generating of a token in the "Temporary unpublished access" section of the node edit sidebar.
Because of the lack of this, a workaround I used was a hook_form_alter() implementation to control the display of the "Temporary unpublished access" section of the node edit sidebar.
if (isset($form['access_unpublished_settings'])) {
$current_user_roles = \Drupal::currentUser()->getRoles();
// Hide access unpublished functionality from certain user roles to prevent
// non-admin users from generating tokens for unpublished access.
if (!in_array(['editor'], $current_user_roles)) {
$form['access_unpublished_settings']['#access'] = FALSE;
}
}
But, I believe this we could create a permission for generating a token and wrap the code in AccessUnpublishedForm::formAlter() with a check on that permission, if it makes sense for this to be part of the contrib module. I do think it does make sense to give more granular control over who can actually generate the tokens.
Needs review
1.0
Code
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
We needed the ability to restrict token generation by role and the MR seems to do just that.