chris dart → created an issue.
I'm not sure why the pipeline is failing, but I believe this is ready for review. The changes appear to work correctly in a client's installation. So I may have made an error in the test file changes?
chris dart → created an issue.
This automated fix is insuficient. There are other updates that are needed. I will create a separate ticket.
Updated the patch to remove all references to variationcache
This also needs a patch for the composer file. drupal/variationcache is not required for Group 3. This patch is only for Group 3 installations.
This is a puzzle. When I run composer require 'drupal/groupmedia:^4.0' it installs version 4.0.3, but config/optiona/view.views.group_media.yml still has the old default_argument_skip_url even after I have uninstalled and re-installed it.
Why would this be?
chris dart → created an issue.
This branch already has D11 updates for groupmedia_vbo but it is not available for patching. Use this patch to update groupmedia_vbo.
chris dart → made their first commit to this issue’s fork.
chris dart → created an issue.
chris dart → created an issue.
Updated view with more fields.
chris dart → created an issue.
chris dart → created an issue.
chris dart → created an issue.
chris dart → created an issue.
Updated patch file.
Updated transposed letter in original commit. Language code should be fa-AF
chris dart → created an issue.
This may be a little out of date.
"Change this by navigating to the User or Workspace settings page, and clicking the 'Open Settings (JSON)' button in the tab bar." The User and Workspace settings page does not appear to have an obvious tab called Open Settings (JSON)'. A better solution is:
From the "View" Menu choose Command Pallet (or Ctrl-shift-P/Cmd-shift-P) and type "Open Settings (JSON)" and choose "Open Workspace Settings (JSON)" or "Open User Settings (JSON)"
Chris Dart → created an issue.
If there is any reason why one needs multiple ways to access related content, let my obsessive minor re-edits of my original post serve as an example.
Chris Dart → created an issue.
An additional problem for new developers especially is this: all services should be instantiated with the \Drupal::service() method. Yet if you go to api.drupal.org to look up a service, nothing in the documentation tells what the name of the service's tag is. Somehow this needs to be documented in one place or the other. I recognize that it creates a redundancy and also may violate a theoretical best practice, but without this easily accessible, instantiating a given service amounts to special knowledge which runs contrary to the spirit accessible open-source software.
I prefer the idea of using the @service_tag that clearly states a class because the api.drupal.org never tells us how to instantiate a service of the given class. Why separate these when services should never be instantiated except by using \Drupal::service();? This results in what is essentially special knowledge--something that is anathema to FOSS software principles. It should be tightly connected to the class being instantiated. When I develop custom modules that have services I always include the instructions for instantiation in the class PHPDocBlock so that it's easy for others on my team to see. While this does create redundancy, that's more of an architectural flaw if anything. (Why not define the service entirely in a docblock?) But that's a debate for another day.
Chris Dart → made their first commit to this issue’s fork.
Chris Dart → created an issue.
I believe I have found all the queries that were missing an accessCheck() in this patch.
Methods that need fixing:
GroupListBuilder::getEntityIds()
GroupContentListBuilder::getEntitiyIds()
GroupRoleSynchronizer::getGroupRoleIdsByGroupTypes()
GroupRoleSynchronizer::getGroupRoleIdsByUserRoles()
GroupContentCreateAnyAccessCheck::access()
SynchronizedGroupPermissionCalculator::calculateOutsiderPermissions()
GroupType::getRoleIds()
Some of these may need an accessCheck(FALSE), but I could not find the equivalents in newer branches of the project to determine if this would be appropriate. All of the methods above seem to be items that should have permission restrictions, so I left the accessCheck() default to TRUE.
This duplicates work in https://drupal.org/node/3371641 for all accessCheck issues in 8.x-1.x
Chris Dart → created an issue.
Here's a patch while we wait for the magic to happen with the merge request.
Chris Dart → created an issue.
Chris Dart → made their first commit to this issue’s fork.
Here's a patch from the above branch.
Chris Dart → created an issue.
Chris Dart → created an issue.
Chris Dart → created an issue.
Chris Dart → created an issue.
This should default to not show seconds. The chances that a UX will require seconds is far less common than users entering hours and minutes only. Users should override to show seconds not hide them. Probably a better idea to change this than to have developers add hooks or extra modules to display the most likely user need.
This is a critical problem. Developers may like being able to enter exact dates, but end users are very likely to experience errors unless the entering of dates is constrained by some kind of UI abstraction.