Perfect, thank you so much for the quick response and fix!
Ok, we've got a winner. It now works without error when executed normally and when executed in my VBO action. Looks good!
It worked from my VBO action, but I got this error during normal execution:
Warning: Undefined variable $queue in /app/web/modules/contrib/govdelivery_bulletins/src/Service/AddBulletinToQueue.php on line 407 The website encountered an unexpected error. Try again later.
Error: Call to a member function deleteItem() on null in Drupal\govdelivery_bulletins\Service\AddBulletinToQueue->dedupeQueue() (line 407 of modules/contrib/govdelivery_bulletins/src/Service/AddBulletinToQueue.php).
Drupal\govdelivery_bulletins\Service\AddBulletinToQueue->buildXml() (Line: 334)
Drupal\govdelivery_bulletins\Service\AddBulletinToQueue->buildBulletinData() (Line: 285)
Drupal\govdelivery_bulletins\Service\AddBulletinToQueue->addToQueue(NULL) (Line: 301)
Drupal\govdelivery_bulletins\Service\AddBulletinToQueue->addToQueueAndReset() (Line: 417)
It looks like you forgot to replace $queue with $this->queue on lines 407 and 427.
Unfortunately, it's still not working. I get this error now during normal execution and VBO action:
Fatal error: Could not check compatibility between Drupal\govdelivery_bulletins\Service\AddBulletinToQueue::create(Drupal\govdelivery_bulletins\Service\ContainerInterface $container) and Drupal\Core\DependencyInjection\ContainerInjectionInterface::create(Symfony\Component\DependencyInjection\ContainerInterface $container), because class Drupal\govdelivery_bulletins\Service\ContainerInterface is not available in /app/web/modules/contrib/govdelivery_bulletins/src/Service/AddBulletinToQueue.php on line 200
I removed my workaround and applied the patch, but it's not working. Now I get this error during normal execution:
TypeError: Drupal\govdelivery_bulletins\Service\AddBulletinToQueue::__construct(): Argument #1 ($queue_factory) must be of type Drupal\Core\Queue\QueueFactoryInterface, Drupal\Core\Queue\QueueFactory given, called in /app/web/core/lib/Drupal/Component/DependencyInjection/Container.php on line 261 in Drupal\govdelivery_bulletins\Service\AddBulletinToQueue->__construct() (line 191 of modules/contrib/govdelivery_bulletins/src/Service/AddBulletinToQueue.php).
Drupal\Component\DependencyInjection\Container->createService(Array, 'govdelivery_bulletins.add_bulletin_to_queue') (Line: 179)
Drupal\Component\DependencyInjection\Container->get('govdelivery_bulletins.add_bulletin_to_queue') (Line: 197)
Drupal::service('govdelivery_bulletins.add_bulletin_to_queue') (Line: 401)
...
And I get this error when using my VBO action:
ArgumentCountError: Too few arguments to function Drupal\govdelivery_bulletins\Service\AddBulletinToQueue::__construct(), 0 passed in /app/web/core/lib/Drupal/Component/DependencyInjection/Container.php on line 261 and exactly 2 expected in Drupal\govdelivery_bulletins\Service\AddBulletinToQueue->__construct() (line 191 of modules/contrib/govdelivery_bulletins/src/Service/AddBulletinToQueue.php).
Drupal\Component\DependencyInjection\Container->createService(Array, 'govdelivery_bulletins.add_bulletin_to_queue') (Line: 179)
Drupal\Component\DependencyInjection\Container->get('govdelivery_bulletins.add_bulletin_to_queue') (Line: 197)
Drupal::service('govdelivery_bulletins.add_bulletin_to_queue') (Line: 401)
...
FYI I was able to create a temporary workaround by modifying my code as follows:
// Load the Twig theme engine so govdelivery_bulletins can use twig_render_template() when called from a VBO action.
include_once \Drupal::root() . '/core/themes/engines/twig/twig.engine';
$twig = \Drupal::service('twig');
$twig_debug = $twig->isDebug();
if ($twig_debug) $twig->disableDebug();
\Drupal::service('govdelivery_bulletins.add_bulletin_to_queue')->addToQueueAndReset();
if ($twig_debug) $twig->enableDebug();
richarddavies → created an issue.
Thanks. You should also consider updating the example code on the module homepage to use the new method.
Thank you for the quick response. Yes, I tested addToQueueAndReset() and it worked as expected.
richarddavies → created an issue.
Reopening because you shouldn't need to completely reconfigure your views just because you add bulk operations to a certain display.
richarddavies → created an issue.
In case this helps anyone, while developing a custom VBO action I got the same error after I changed my action's plugin ID. The error said it couldn't find the old plugin ID, and I couldn't find any references to the old ID anywhere in my code or config. Finally I realized I had been testing the plugin and apparently had left an item checked on my VBO form when I changed the ID value. VBO stores some temporary data related to which items are checked, along with the selected action in the database key_value_expire table so that if you reload the view it can restore your set of checked items.
Anyway, I had to delete some rows from that database table:
delete from key_value_expire
where collection = 'tempstore.private.views_bulk_operations_[view_id]_[display_id]'(replace [view_id] and [display_id] with your appropriate values)
Alternatively, I guess I could have reverted back to the original plugin ID, made sure to uncheck all items on the view, and then change the plugin ID to the new value.
Yes, choosing the best title is not always going to be without challenge. Sometimes you may need to be a little more generic or focus on the most common symptoms, but even then it's way more user-friendly than a title based on the low level fix/change that was made.
Sure, the issue may currently still show up in issue search results, but good luck trying to correctly identify the right one from the other 20+ issues when all of them have meaningless titles that don't relate at all to the problem you're experiencing. You're forced to randomly click on various issues hoping to get lucky.
I still maintain that the best title describes the "business value" or change from the end-user perspective, not the underlying technical implementation details. For example, "Fix various permission issues causing missing buttons/links to add/edit group membership and content" is a much better description of what this issue fixes and how it improves the module over "Automatically set all relation handlers and decorators as 'shared: false'". The technical implementation is only a means to an end. Focus on the end goal, not how you got there.
There's a similar problem if you enable Views Bulk Operations on a view embedded as a block. The bulk operations also incorrectly target the wrong page path. However, in this case, enabling AJAX doesn't work as a workaround. So you're telling me that now I need to recreate this block in a completely new separate view and reconfigure my pages/blocks just because I've added bulk operations and this is by design?
I'm sorry, but if this is "works as designed" then I think this is poorly designed. Please explain to me why I'd want the exposed filters in my view block to target another random display in that view. You said it uses the "first" display with a path, but it doesn't use the first display according to the configured display order within the view, it uses the first display defined in the view's YAML config file.
If this works as expected with a view containing only a single block, then it should work the same with a block in a view that also contains other displays.
Thank you again!
One piece of general feedback though regarding these issues, wouldn't it be better to name the issue based on the symptom/problem instead of the solution? As a Drupal user, if I have a problem and I'm searching through the issue queue to see if there's a related issue, I'm going to have a harder time finding it if it's named based on the solution or fix because all I know is what symptoms or errors I'm currently seeing. For example, this issue's current title doesn't give me any clues as to what problem this issue addresses.
Thank you! I just want to confirm that this fix will also be applied to the 2.3 branch, right?
I can also confirm it has resolved both the missing Add member button and being able to edit group memberships that you didn't create.
My testing was on Drupal 10.3.5.
I have the same issue as #21 and #25. I tried both the patch in #5 and MR 36. Both fixed the Preview button so that it works again, but only when initially clicked. After I close the preview window the Preview button doesn't work anymore. I have to refresh the edit media page before I can use the Preview link again. This makes it very challenging to preview multiple focal points.
Here are the console logs from my browser showing the initial request from the preview link that worked, followed by the request from the second preview link click which doesn't work due to a JavaScript error:
I was able to reproduce this issue with a clean install of Drupal 10.3.7. Here are the steps to reproduce:
1. composer require drupal/group:^2.3
2. drush en flexible_permissions entity group gnode group_support_revisions
3. Create a group type named "Base group" at /admin/group/types
- Check "The group creator automatically becomes a member"
- Uncheck "Group creator must complete their membership"
- Check "Automatically configure useful default roles"
- Check "Automatically configure an administrative role"
- Check "Automatically assign this administrative role to group creators"
4. Install node content plugins using default settings for Article and Basic Page at /admin/group/types/manage/base_group/content
5. Create a group named "Group One" at /admin/group
6. Go to group page at /group/1 and click Members tab
7. Notice there's no "Add member" button on /group/1/members despite being listed as a member of the group with the Admin role
8. Disable Group Support Revisions module with drush pmu group_support_revisions
9. drush cr
10. Refresh /group/1/members and notice that the "Add member" button is now visible
Also, interestingly I do technically have the permissions necessary to add a member by manually going to /[group]/content/add/group_membership, even though the button doesn't appear on the group membership page. Likewise, I can edit memberships by manually going to /[group]/content/[id]/edit, even though the edit links don't appear on the group membership page or on /[group]/content/[id]
So it seems that it's only miscalculating my permissions when deciding whether or not to show the buttons/links.
I'm also having issues adding/editing group memberships with Groups 2.3.0. On my /[group]/memberships page, the "+ Add member" button is gone and I can only edit memberships that I created, even though I have the administrator role and have configured the appropriate insider and outsider group roles that sync with the sitewide administrator role.
The Add member button and Edit membership links appear if I uninstall the group_support_revisions module or if I downgrade to Groups 2.2.2 and Flexible permissions 1.1.0.
I'm getting the same error during drush updb after upgrading from Group 1 to Group 2.3. I tried the patch mentioned in the previous comment but still got the same warning messages.
Patch for Group 2.x in #15 won't apply to Group 2.3. Here's an updated patch for Group 2.x.
I recently went through this same issue with a Group 1 -> 2 upgrade. As others have already mentioned, the error was caused by orphaned records in the group_content and group_content_field_data tables. For those looking for more details about how to identify such orphaned records, here are two SQL queries that worked to clean up our orphaned records:
delete from group_content_field_data where id in (
select gcfd.id from group_content_field_data gcfd left join groups on gcfd.gid = groups.id where groups.id is NULL
);
delete from group_content where id in (
select gc.id from group_content gc left join group_content_field_data gcfd on gc.id = gcfd.id where gcfd.id is NULL
);
The first query deletes orphaned records from group_content_field_data that are assigned to a group that no longer exists. The second query deletes orphaned records from group_content that don't have a corresponding record in group_content_field_data (either because the field_data record was just removed by the first query or due to some other previous data corruption issue).
If that doesn't resolve it, I would look for records in both tables whose field type value is invalid. The type value should correspond to one of your group content plugins' machine name/ID defined at /admin/group/types/manage/[group_type]/content. (Hover over the Configure button and look at the URL to see the machine name/ID.)
I can also confirm that the MR removed the error message for our site.
Rerolled patch for Drupal 10.3.1.
Similar to @mariacha1 in comment 12, I started having this problem when I added a facet to a Search API view. The facet was for a "tags" taxonomy which has about 200 terms in it. Pages on our site can have one or more tags associated with them, and I wanted to allow users to filter their search results by a selected tag.
Interestingly, disabling the facet setting "Transform entity ID in aggregated field to label" made the error go away, but this wasn't an acceptable workaround because I need the facet to display the term's name instead of the term ID. Additionally, I found that setting a hard limit of 250 items on the facet also prevented the error, which was the workaround I ultimately went with.
I can confirm patch in #12 worked for us.
I agree a UI option to enable/disable cron processing of the queue would be ideal. But as a workaround, here's some code I've added to a custom module to make the cron process the queue:
/**
* Implement hook_cron()
*/
function MYMODULE_cron()
{
$queue_worker = \Drupal::service('plugin.manager.queue_worker');
$bulletinQueue_worker = $queue_worker->createInstance('govdelivery_bulletins');
$bulletinQueue_worker->processQueue();
}
(Replace MYMODULE with the name of your custom module.)
Thanks for the explanation. The performance and reliability aspects make sense, as well as the UI only being a developer/debugging tool.
I agree, it would be ideal if there was a setting to have the cron send any queued items. But we can workaround that limitation using one of the methods you suggested. The second method of using the API trigger endpoint does require a Unix timestamp (it would be nice if it defaulted to the current time) but I suppose we could just use a very far future timestamp in every request if we don't want to have to programmatically calculate a timestamp.
This is probably my biggest sticking point with the module right now (figuring out how to bypass or automate sending the queue) so any advice here would be greatly appreciated. Thank you!
FYI When this happened to me, it truncated the message at the critical part. i.e. "An error occurred because you must... (truncated)". I ended up having to use Postman with the XML shown on the queue page to manually issue the API call and reproduce the error so I could see the full message.
swirt → credited RichardDavies → .
swirt → credited RichardDavies → .
swirt → credited RichardDavies → .
swirt → credited RichardDavies → .
swirt → credited RichardDavies → .
swirt → credited RichardDavies → .
RichardDavies → created an issue.
Thank you for the quick response. I applied the patch from the MR and it fixed the problem. I no longer get the errors on /admin/structure/block/manage/[theme]_breadcrumbs/settings-tray and the modified help text for the Pages field is still present on /admin/structure/block/manage/westy_breadcrumbs
RichardDavies → created an issue.
RichardDavies → created an issue.
RichardDavies → created an issue.
Ah, thanks, I didn't realize I could edit that documentation. I've removed that row and made a couple of other additions to improve it.
Regarding static vs non-static, no, my VS Code editor doesn't alert to to that issue. Perhaps I don't have it configured correctly. Just goes to show you can't assume everyone's using an IDE that would point that issue out. I guess I just feel that a section of documentation that is dedicated to listing API changes should state when a method changes from static to non-static because that's just as important of an API change as the method name changing or parameters changing.
- Corrected incorrect information about removal of
GroupRelationship::loadByEntity()(Method wasn't actually removed) - Added additional information about new methods for old methods that used to support filters.
Yes, I eventually figured it out. But I do feel this is a good example of how you could make your documentation clearer and easier to understand because technically the documentation is currently incorrect.
You have a section describing changes to the GroupContent/GroupRelationship class which says that the loadByEntity method was removed. This is incorrect because that method still exists and works just fine (and actually does what the documentation recommends doing instead).
Don't state that a method has been removed if it hasn't actually been removed. (And if it was actually removed and the old method was static but the new method is not static, then you should state that change in the documentation when you mention the new method's name so that we don't have to go hunting through the source code to figure it out.)
I would recommend just removing that entire table row from the documentation because loadByEntity was not removed so the user doesn't need to do anything other than use the new class name.
FYI I filed a bug report with Drush for the extra blank lines: https://github.com/drush-ops/drush/issues/5911
Update:
After further review, GroupRelationship::loadByEntity() is actually working correctly for me. So I assume that's the correct function to use, and it does actually use \Drupal::entityTypeManager()->getStorage('group_content')->loadByEntity() under the hood.
So I just think the documentation is not very clear when it says "Use GroupRelationshipTypeStorage class and it's loadByEntity method" because that lead me to mistakenly think I should replace GroupContent::loadByEntity() with GroupRelationshipTypeStorage::loadByEntity()
Nevermind, I think I just found the answer. It looks like in this specific case, I can use getRelationshipsByEntity($entity, $plugin_id)
RichardDavies → created an issue.
Before I reviewed that documentation page, I just assumed the method changed to GroupRelationship::loadByEntity() which interestingly does exist, but it doesn't seem to be working as expected for me. It's not returning any entities when there should be some.
So I'm not sure if the documentation is wrong, or if there's a bug in the new function, etc.
RichardDavies → created an issue.
Thank you, I finally got to the bottom of my issue. It was indeed caused by some of our custom code that maintains some automatic group memberships based on some data from the user's Active Directory profile. This code was calling Group::load($group_id)->getMember($account)->getRoles() which returns all roles, even our new insider/outsider roles, and then it was unintentionally assigning those roles to the user. Changing it to getRoles(FALSE) fixed the problem.
kristiaanvandeneynde → credited RichardDavies → .
My "other suggestions" in #18 were in direct response to your question in #17 "I think this is rather clear, no?". So I'm confused as to why you think this was not the right place for that response... Obviously you can do whatever you want with my feedback--take it or leave it, create a new issue for it, incorporate it into a future release, etc. But if you'd prefer not to receive feedback in a closed issue, then maybe best not to ask for it there. :)
I'm having a similar issue, but not sure if the problem is something on my end or a bug in Groups module. I'm upgrading a site which was using Groups 1.6 to 2.2. The site has the concept of an "public" group which any authenticated user can view without being a member. I've configured an Outsider scoped role that is synced with authenticated users to allow non members to view the group. There are also Outsider and Insider roles synced with the global administrator role so admins can manage all groups.
If a user views a group and they're interested in it, they can "follow it" which means becoming a member and being assigned the "following" individual-scoped role. However, whenever a user tries to follow a group, they get the permission error mentioned in the original post. Group admins also get the error when they click the Add member button on a group and try to add themself with the "following" role. However, if they add any other user beside themself then they don't get the error.
I've debugged the IndividualGroupPermissionCalculator as suggested and it is also returning an insider scoped role (either the "member" role synced with authenticated users or the administrator role synced with global admins). You said this means that "You have an insider role assigned to someone"... but I've looked at all of the groups that I'm a member of found one where I was assigned the "member" role and removed that role but I'm still getting the error. So does the error mean that the user being added to the group is assigned an insider role somewhere that I've missed somehow, or will I get the error if ANY user on the site is assigned an insider role (because it's possible we might have other others still assigned the "member" role)
I'm experiencing another issue related to the `separator: |+` config line and extra rows. I'm finding that `drush cex` often wants to insert additional blank lines under the separator line. It doesn't seem to matter how many blank lines are already there, it keeps adding another one every time I export the configuration. Interestingly, when it lists the config that will be exported, search_api.index.my_index isn't listed as having changed, but the yml file is still modified with an additional blank line when the export is executed.
As someone upgrading from Groups 1 to 2 I hadn't actually seen this text until just now, so although it's helpful to new users, it doesn't really help users who are migrating and have already created their groups under a previous version of the module. Regardless, it is reasonably clear to me, but I think it could still be improved a little. Here's my suggested version:
Please note that Drupal accounts, including user 1, do not have access to any groups unless configured so. It is therefore important that you at the very least do one of the following:
- Assign the group creator a role below and set some permissions on that role. You can edit this group type at any time to set more creator roles, but this won't affect previously created groups.
- Allow certain global roles to automatically get some group permissions via Outsider or Insider group roles.
Optionally, you can set a role (whether the group creator's role or an Outsider/Insider role) as an admin role if you want that role to have all permissions for the group. If your use case does not require the group creator to be an admin of the group, then it is strongly advised to at least create an Outsider and/or Insider group role that synchronizes with whatever administrator global role you have configured.
* Note that the word "administrator" is currently misspelled in your last sentence.
I certainly appreciate all of your work on this module. Now that I understand the change, I can see that all of the information was there, albeit spread across release notes, change records, and videos. But for someone trying to understand this for the first time, it's difficult to have to go to multiple sources to glean little tibits of information and successfully assemble all of the puzzle pieces together in order to form a complete mental understanding.
I can only speak for myself, but since you asked, an explanation like the following in the release notes would have been easier for me to understand:
Roles and their UI have been reworked
No more advanced outsider roles or any of that nonsense. You can now define one of three roles:
- Outsider: This group role is automatically assigned to all users who are not a member of the group and have a specific global role.
- Insider: This group role is automatically assigned to all users who are a member of the group and have a specific global role.
- Individual: This group role can be manually assigned to a specific group member to give them extra permissions on top of the above.
For example, in order to give all group members admin permissions if they have the global role "Site administrator", do the following:
1. Create a group role "Site Administrator"
2. Scope: Insider
3. Global role: Administrator
4. Check "Admin role"
This group role will now sync with the site role "Site administrator".
@JordiK Thank you for providing simple instructions on how to recreate the version 1's sitewide administrator permissions. Despite having read the release notes multiple times, this change was not clearly explained in my opinion (e.g. it wasn't obvious to me that the new group roles could be auto assigned to users with a specific sitewide role.)
Anyway, I just wanted to point out that to fully recreate version 1's sitewide administrator access to all groups, you need to create two new roles: an "insider" one like you mentioned, and a corresponding one with scope set to "outsider". That way a user with the sitewide administrator role will have admin access to any group, regardless of whether they're a member of it or not.
@dqd You just barely said in your previous comment that you're considering closing this issue since Drupal 7 is EOL soon. Why not just repurpose this existing ticket (with all it's history) for the same issue with D10 and Conditional Fields 4.0? Seems pointless to close this ticket and reopen a new one for the same issue.
RichardDavies → created an issue.
I'm experiencing the same issue with Drupal 10 and Conditional Fields v4. So I think this should remain an open issue.
This module is now being flagged as unsupported. Can we get a new release soon? This patch has been working fine for us.
RichardDavies → created an issue.
Updated @shweta__sharma's patch and changed key() to keys(). Patch now cleanly applies for me in 10.2.0.
@shweta__sharma Thank you, but the patch won't apply for me with 10.2.0:
@acbramley Ah, thank you for the clarification. I didn't understand how the 11.x branch worked and couldn't find this item listed in any of the 10.2x release notes so I assumed it wasn't in the 10.2 release. But I've just confirmed it is indeed there.
Can someone please reroll the patch for Drupal 10.2.0?
Can someone please reroll the patch for Drupal 10.2.0?
RichardDavies → created an issue.
I encountered the following error when attempting to upgrade from v1.6 to v2.0.2
Drupal\google_tag\Migration\GoogleTagMigrateBase::getRequestPathCondition(): Argument #1 ($request_paths) must be of type string, null given, called in /app/web/modules/contrib/google_tag/src/Migration/GoogleTagUpgradeManager.php on line 126
Although this patch allowed me to run the database update without error, it does not appear to have correctly/fully migrated my previous container settings. For example, here is my previous container YAML:
uuid: 0c9d3f73-ef36-48ab-9c86-28b4cc41bc2b
langcode: en
status: true
dependencies:
module:
- webform
id: employees_portland.gov
label: 'Employees Portland.gov'
weight: 0
container_id: GTM-[REDACTED]
data_layer: dataLayer
include_classes: false
whitelist_classes: |-
google
nonGooglePixels
nonGoogleScripts
nonGoogleIframes
blacklist_classes: |-
customScripts
customPixels
include_environment: true
environment_id: env-3
environment_token: [REDACTED]
path_toggle: 'exclude listed'
path_list: |-
/admin*
/batch*
/clone/*
/devel/*
/node/add*
/node/*/edit
/node/*/delete
/node/*/revisions
/node/*/usage
/user/*/edit*
/user/*/cancel*
/user/*/scheduled*
/user/*/connected-accounts
/user/*/submissions
/group/*/edit
/group/*/delete
/group/*/content*
/group/*/nodes
/group/*/revisions
/group/*/members
/group/*/media*
/group/*/usage
/group/*/subgroups
/group/*/create
/media/*/edit
/media/*/delete
/media/*/usage
/taxonomy/*/edit
/taxonomy/*/delete
/taxonomy/*/usage
role_toggle: 'exclude listed'
role_list: { }
status_toggle: 'exclude listed'
status_list: |-
403
404
conditions: { }And here is the new YAML:
uuid: 0c9d3f73-ef36-48ab-9c86-28b4cc41bc2b
langcode: en
status: true
dependencies: { }
id: employees_portland.gov
label: 'Employees Portland.gov'
weight: 0
tag_container_ids:
- null
advanced_settings:
gtm:
data_layer: dataLayer
include_classes: false
allowlist_classes: ''
blocklist_classes: ''
include_environment: false
environment_id: ''
environment_token: ''
dimensions_metrics: { }
conditions: { }
events:
search: { }
webform_purchase: { }
login:
method: CMS
custom: { }
generate_lead:
value: ''
currency: ''
sign_up:
method: CMS
As you can see, it didn't transfer the container ID, environment, or path exclusion settings.
RichardDavies → created an issue.
@hudri Thank you for figuring this out and providing a fix. We were experiencing the exact same error and I couldn't figure out why until I found this bug report and discovered we were also unsetting the administration menu just like you were in order to hide it from certain users. Your fix works perfectly!
Patch #39 works for me. I'm now able to use the To filter on /admin/config/search/redirect to search by URL alias values shown in the To column. Searching by the internal node ID still works as well.
Moving this issue to https://www.drupal.org/project/lightning_workflow/issues/3176759 🐛 Lightning Workflow-created revisions not getting correct time Active because we're using the lightning_scheduler that is included with lightning_workflow.
We're also having this same problem with v3.19. I see that supposedly this was previously fixed with https://www.drupal.org/project/lightning_workflow/issues/3022898 → so I'm not sure why it still doesn't seem to be working correctly.
RichardDavies → created an issue.
RichardDavies → created an issue.
Hmm, I'm trying config_ignore for the first time and seeing my config split entities appear as ignored in the config UI. I'm using version 2.4.0.
In case anyone else runs into this issue, here's a patch to remove the redundant Revisions tab that's now being added by Groups. (The other tab is coming from Drupal 10's system.links.task.yml.)
After upgrading to Drupal 10, all of my groups now have two "Revisions" tabs:
Both tabs link to /[group_alias]/revisions. I'm using Groups 1.5 and Drupal 10.1.2.
This is a confusing warning. The Classy and Stable themes are part of Drupal 9 core and are both located in the web/core/themes directory. So you can't uninstall them like you would with a contrib theme that has been added to your site. You should verify that you're not using another theme that relies on either of those themes as a base theme. As long as they're not being used directly or as a base theme, they should just silently go away when upgrading to Drupal 10.
But, like you reported, I don't know how to satisfy the upgrade status report so that it doesn't complain about these themes even if I'm not using them. So for now I just ignore that warning.
For some reason Composer would not apply the given patch file for me. I had to manually recreate the patch file to get it to successfully apply.
No, I don't think I did other than to manually translate the view through the native Drupal translation UI.
Updating the issue summary with more information.