The OG role 'og_role' entity should not extend core's 'role'

After merging the 📌 Group roles and permissions UI Active I replaced Role class from core from the OgRole exends with ConfigEntityBase like it does and copied all the code up to OgRole, so it should in theory work the same as it did before... Though I am human so likely made a mistake, though I tried to make the changes as "diffable" as I could

@claudiu.cristea I didn't remove the comment yet as I did a close to a straight copy over. But once I can confirm its resolved I will remove it.

When adding a new role in the UI, this is what we get

The website encountered an unexpected error. Try again later.

Drupal\Core\Entity\Exception\UndefinedLinkTemplateException: No link template 'canonical' found for the 'og_role' entity type in Drupal\Core\Entity\EntityBase->toUrl() (line 211 of core/lib/Drupal/Core/Entity/EntityBase.php).

Drupal\Core\Config\Entity\ConfigEntityBase->toUrl() (Line: 259)
Drupal\Core\Entity\EntityBase->toLink() (Line: 105)
Drupal\og_ui\Form\OgRoleForm->save()
call_user_func_array() (Line: 129)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers() (Line: 67)
Drupal\Core\Form\FormSubmitter->doSubmitForm() (Line: 597)
Drupal\Core\Form\FormBuilder->processForm() (Line: 326)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
Drupal\Core\Controller\FormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 638)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 90)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 741)
Drupal\Core\DrupalKernel->handle() (Line: 19)

This is worth a look, I think it's in a good spot to see if I missed anything.

@joelpittet Thanks, I see phpstan is failing.

@claudiu.cristea, would you like to review before merging?

Permissions aren't saving on the role after this, and missing the default mapped, roles for member, non-member, administrator

Split off the UI issue here so it can be addressed independently
🐛 UndefinedLinkTemplateException when adding a new OG role in the UI Active

This targets 2.x branch. We can consider back porting to 8.x-1.x. Please change MR's base branch, I have no permissions

Probably we should not backport to avoid any issue

Yeah I am ok not backporting this.

@amitaibu and @claudiu.cristea,

While working on this, I’m not finding “real” permissions. The code isn’t detecting ‘administer group’, and it’s getting removed in OgRole::calculateDependencies().

This line: $permission_definitions = \Drupal::service('user.permissions')->getPermissions(); isn’t returning the expected results.

I’m unsure about the intended behaviour—are we relying on Drupal’s permissions, or are we using our own? If it’s the latter, I can dig in further, but I’m currently hitting a wall. Any insights?

RE #14 This commit might be correct considering the comment I removed. https://git.drupalcode.org/project/og/-/merge_requests/19/diffs?commit_i...

> are we relying on Drupal’s permissions, or are we using our own?

On the Site's level there's only the `administer groups`, that should give a site admin all access to all groups.
Then, the rest of the permissions are on the OG level.

joelpittet → changed the visibility of the branch 8.x-1.x to hidden.

I've merged this into 2.x branch. All the tests and some quick manual tests show it's working the same as it did before.

joelpittet → credited ramil g → .

Automatically closed - issue fixed for 2 weeks with no activity.