🇦🇺Australia @chOP

voleger → credited chOP → .

froboy → credited chOP → .

It appears that this patch and automated commit were already merged to the working default branch 2.0.x.

See branch here:
https://git.drupalcode.org/issue/webform_invitation-3290630/-/tree/2.0.x...

See commit here:
https://git.drupalcode.org/issue/webform_invitation-3290630/-/commit/a06...

This issue should be closed as fixed.

Any new release of the 2.0.x branch should now contain the changes that were proposed here.

This is a problem for anyone using Group v2.x or Group v3.x

Group v1.x is no longer recommended.

An upgrade path exists from Group v1.x to Group v2.x.

New sites will often install Group v3.x.

Consider removing Group v1.x support entirely.

You're in a sticky situation by having this integration code but no real way to tie it to a specific version of Group. The idea of moving this integration code out into a submodule with defined dependencies and version constraints makes some sense. The current implementation uses a common method from before we had Composer support in Drupal. I understand why it was done this way, but it might be done differently now.

LGTM

DamienMcKenna → credited chOP → .

works for me also. RTBC

Also seeing this uncaught exception error after fixing the first.

Error: Call to a member function access() on null in Drupal\group\Entity\Controller\GroupRelationshipListBuilder->getDefaultOperations() (line 153 of modules/contrib/group/src/Entity/Controller/GroupRelationshipListBuilder.php). 

with the call stack

Drupal\Core\Entity\EntityListBuilder->getOperations() (Line: 212)
Drupal\Core\Entity\EntityListBuilder->buildOperations() (Line: 194)
Drupal\Core\Entity\EntityListBuilder->buildRow() (Line: 119)
Drupal\group\Entity\Controller\GroupRelationshipListBuilder->buildRow() (Line: 242)
Drupal\Core\Entity\EntityListBuilder->render() (Line: 126)
Drupal\group\Entity\Controller\GroupRelationshipListBuilder->render() (Line: 23)
Drupal\Core\Entity\Controller\EntityListController->listing()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 583)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 166)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 74)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 58)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 270)
Drupal\shield\ShieldMiddleware->bypass() (Line: 137)
Drupal\shield\ShieldMiddleware->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 704)
Drupal\Core\DrupalKernel->handle() (Line: 19)

chOP → created an issue.

+++ b/src/Entity/Form/GroupTypeForm.php
@@ -238,7 +238,11 @@ class GroupTypeForm extends BundleEntityFormBase {
+        if (array_key_exists('creator_roles', $form)) {
+          if (array_key_exists('#description', $form['creator_roles'])) {

This might be expressed more simply using

if (isset($form['creator_roles']['#description'])) {

Queued tests of patch from #4 with Group v2.1.x

This is interesting.

Looks like safedelete is passing a Group Node id (gnode) as if it is a node id. Then it looks for references, but cannot load a node with that id, because it isn't a node id. Its a gnode id.

Oops.

I looked through the code in safedelete_form_alter() and there might be a problem where safedelete thinks it's altering a node delete form, but its actually altering a gnode delete form.

Oh dear.

chOP → created an issue.

Link to the official documentation to explain Azure AD OAuth2.0 OIDC Endpoint configuration options.

After you install the module, navigate to the the admin page at

Manage > Configuration > Search > URL Redirects
/admin/config/search/redirect

Now open the Migrate tab. The Redirect migrate form provides this help text describing the format to use - see screen shot below.

CSV files need to have a header row with the column names as follows:

source,destination,language,status_code

When you do not include this header row, the redirect import will fail. The error messages shown when you do not include a header row with these columns is a bit confusing.

There is an open issue to improve the validation. See 🐛 Warning messages appear when the CSV's header are not following the suggested headers Fixed for that improved validation fix.

Hope this helps.

Same as @efrainh above, we fixed the problem by adding the header row to the start of our CSV.

The errors generated are not helpful in identifying and fixing the problem. We've raised a new issue 🐛 Warning messages appear when the CSV's header are not following the suggested headers Fixed to improve the validation by introducing a check to ensure that a header row has been included in the CSV.

If you encounter this problem can you try the issue 🐛 Warning messages appear when the CSV's header are not following the suggested headers Fixed patch first before commenting out validation code. Let's see if we can improve the validation.

LGTM

Marking as needs review.

I have the following questions...

1. +++ b/src/Form/MigrateRedirectForm.php
   @@ -171,6 +171,19 @@ my-source-path,https://example.com,und,302',
   +          $file->delete();
   

   Do we need to delete the file during validation when it doesn't contain the correct CSV header row?

2. +++ b/src/Form/MigrateRedirectForm.php
   @@ -171,6 +171,19 @@ my-source-path,https://example.com,und,302',
   +          break;
   

   Should we return rather than break here?

I note that the class is already using t() calls and doesn't use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead. This is probably something to address in a separate issue I suppose.

+++ b/src/Form/MigrateRedirectForm.php
@@ -171,6 +171,19 @@ my-source-path,https://example.com,und,302',
+          $csvHtml = t('Header line shoud follow the following labels: source,destination,language,status_code');

t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead

chOP → created an issue.