Problem/Motivation
It is a big challenge for some site to go to group 3.x and they already have unsupported warning with this module so going to group 2.x is the easier way. And group_notify do not support that version at least there few issues about that.
Steps to reproduce
In your site which already have installed the module group and group_notify update group to 2.x and group_notify to 2.0.0-beta1, then you will see error about unfound entity type 'group_relationship'.
Proposed resolution
In seems the only issue in this module is about the entity_type_id we provide to services, currently the module use 'group_relationship' for the version 3 need. We can make it generic the module check the version of group and give the entity_type_id.
Remaining tasks
Make a patch or MR.
User interface changes
NA
API changes
NA
Data model changes
NA
| Comment | File | Size | Author |
|---|
Issue fork group_notify-3436167
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3436167-group-v2-api
changes, plain diff MR !13
Comments
Comment #2
diaodiallo commentedHere is a patch to support both versions.
Comment #3
phjouThe requirement in the info file also makes it impossible to use:
dependencies:
- group:gnode (>=3.2.0)
I am not sure why that has been added but it seems too restrictive. Version 2 is still supported by group.
Comment #4
phjouNew patch removing the hard requirement in the info file.
But the legitimate question is should we have 2 different branches like the Group module?
Comment #5
phjouThat's the patch for the beta1 if people need it since the release add some lines at the bottom of the info file that are not in the repo.
Comment #6
phjouEDIT: sorry my browser submitted my answer twice
Comment #7
phjouComment #8
diaodiallo commentedThank you @phjou for your patches, I will check it and let you know.
Comment #9
diaodiallo commentedI reviewed the patch group-notify-beta1-3436167.patch. I think can go to RTBC.
Comment #10
dwwThanks for this! Agree this is probably worth doing. However, before this can be committed, this needs some work:
version_compare()call everywhere. I'd rather add a helper method togroup_notify.modulethat returns the right string and then use that helper everywhere.composer.jsonfile so we can do more accurate version constraints. We need to alter that, instead of messing withgroup_notify.info.ymlThanks again! I hope to get this resolved before the next 2.0.0 release (which I aim to be rc1).
Comment #11
dwwI'm working on this now, stay tuned.
Comment #13
dwwMR !13 resolves all my concerns in #10:
version_compare()everywhere.composer.jsonAlso expanded
.gitlab-ci.ymlto add a bunch of manual build/test jobs for various combinations, and added a default build/test for D10.5 + Group 2.3.x.All that seems to be fine. However, this is concerning:
https://git.drupalcode.org/project/group_notify/-/jobs/7360162
Fails locally, too. #3558643: Add basic notification test coverage is failing with:
That's where the test posted an article to a group, and expected notifications to go out to 2 group members, but no emails were found. Perhaps the test itself is broken in Group V2, but perhaps something else more sinister is broken...
I'll keep digging for now.
Comment #14
dwwHuzzah. So glad I added
GroupNotifyTest. 😅 This was indeed broken, and not sending any notifications with Group V2. That's because in Group V3 we rely ongroup_notify_group_relationship_insert()to notice when something is added to a group. But that entity doesn't exist in Group V2, and we need to also implementgroup_notify_group_content_insert():https://git.drupalcode.org/project/group_notify/-/merge_requests/13/diff...
With that change, the test is passing locally. Let's see what the bot thinks...
Comment #15
dwwYay, https://git.drupalcode.org/project/group_notify/-/pipelines/665530 is happy everywhere. I'm going to merge this.
Comment #17
dwwThanks @diaodiallo and @phjou for getting this started! This will now be included in the next 2.0.x release.