Skip to content
This repository has been archived by the owner on Aug 18, 2024. It is now read-only.

Throw an exception when calling MembershipManager::getGroupIds() with an entity which is not group content #311

Merged
merged 6 commits into from
May 10, 2019

Conversation

pfrenssen
Copy link
Contributor

@pfrenssen pfrenssen commented Sep 18, 2017

While working on a test for #296 I noticed that og_invalidate_group_content_cache_tags() calls MembershipManager::getGroupIds() even when the entity is a group and not group content. This is useless, ::getGroupIds() only works on group content and is clearly documented as such.

This results in a useless method being called and its useless results cached every time one of the entity hooks is firing on a group entity. Let's fix the bug and also throw an exception when the wrong entity is being passed, so that developers are alerted if they are using the method incorrectly.

@pfrenssen
Copy link
Contributor Author

The schema errors are possibly due to https://www.drupal.org/node/2870971.

og.module Outdated
// 'og-group-content:{group entity type}:{group entity id}'.
if (Og::isGroup($entity->getEntityTypeId(), $entity->bundle()) || Og::isGroupContent($entity->getEntityTypeId(), $entity->bundle())) {
if (Og::isGroupContent($entity->getEntityTypeId(), $entity->bundle())) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This check to see whether the entity is a group is useless, in MembershipManager::getGroupIds() the queries are performed on group audience fields. If there are no group audience fields it won't return any results.

// The entity might be a user or a non-user entity.
$groups = $entity->getEntityTypeId() == 'user' ? $this->membershipManager->getUserGroups($entity) : $this->membershipManager->getGroups($entity);

if ($is_group_content && $groups) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We already know at this point whether the entity is group content, so a small reshuffle of these two lines into the if statement is sufficient to not do an unneeded call to MembershipManager::getGroups().


entity_reference_selection.og:default:
type: entity_reference_selection.default
label: 'OG entity selection handler settings'
Copy link
Contributor Author

@pfrenssen pfrenssen Sep 19, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Schema change required due to https://www.drupal.org/node/2870971 - I can split this off to a separate ticket if required.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's try leaving this out, this hasn't proven to be problematic in the last 10 months so it was maybe a temporary hiccup that is no longer needed.

og.module Outdated
@@ -317,8 +317,7 @@ function og_entity_type_alter(array &$entity_types) {
function og_invalidate_group_content_cache_tags(EntityInterface $entity) {
// If group content is created or updated, invalidate the group content cache
// tags for each of the groups this group content belongs to. This allows
// group listings to be cached effectively. Also invalidate the tags if the
// group itself changes. The cache tag format is
// group listings to be cached effectively. The cache tag format is
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change should be undone, the code is now effectively checking if the group itself changes, this was added in #337.

@pfrenssen
Copy link
Contributor Author

Haha Github doesn't allow me to reject my own changes 😁

@pfrenssen
Copy link
Contributor Author

The schema change can just be removed, it has already been fixed in #323 by @claudiu-cristea. It is now duplicating it. I will clean this up and then rebase to clean up the commit history.

…e deleting them.

This check only makes sense for group content entities.
This does a needless query, and now also throws an exception.
@pfrenssen
Copy link
Contributor Author

OK this is looking good now. Some of the changes that were included here have been solved in other PRs in the meantime, so It is easier to read. It should be pretty easy to review now.

@tatarbj
Copy link

tatarbj commented Jul 6, 2018

For me it seems a bit over of the original scope, maybe renaming the PR would make sense. Apart of it as we've also discussed there are no other cases when deleteOrphan() will be executed so it seems safe to delete the entity when it's not a group content (else case).
It looks good to me, thanks @pfrenssen for the clear comments, helped me a lot of understand the cases, also the inline comments are clear and proper!

@pfrenssen
Copy link
Contributor Author

Do you mean this comment?

+    // If the entity is not group content (e.g. an OgMembership entity), just go
+    // ahead and delete it.

That is already what was happening before this PR, I just added some documentation here to explain what is going on.

I don't see where this is going out of scope? The PR adds the new exception that is being thrown if the getGroupIds() method is called with a wrong argument. There were two instances where this was called with the wrong argument in our own code, and these two are now fixed by first checking that the entity is group content before calling the method. And a test is added. There is nothing else in the PR?

@pfrenssen pfrenssen requested a review from MPParsley May 10, 2019 08:37
$cache_tags = $entity_type->getListCacheTags();

// The entity might be a user or a non-user entity.
$groups = $entity->getEntityTypeId() == 'user' ? $this->membershipManager->getUserGroups($entity) : $this->membershipManager->getGroups($entity);
Copy link
Collaborator

@MPParsley MPParsley May 10, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or we could test for Drupal\user\UserInterface?

Also use === of you want strict typing

Also might have been useful to have this check within getGroups().

Copy link
Contributor Author

@pfrenssen pfrenssen May 10, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with this proposal but these lines of code are not in fact being changed here, this PR just introduces this single line and moves the related code in it:

if ($is_group_content) {
  // All code in here is in fact unchanged, but shows up in Github as a huge chunk of changed code.
}

I will create a separate PR to implement this suggestion, so this can stay on scope.

Co-Authored-By: Maarten Segers <MPParsley@users.noreply.github.com>
@pfrenssen pfrenssen merged commit 74319ac into 8.x-1.x May 10, 2019
@pfrenssen pfrenssen deleted the reject-non-group-content branch May 10, 2019 18:16
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants