@r.van.doorn

I've only recently updated my project to from 8.1.x to 2.x and ran into the same problem.
At first I wanted to patch the same lines so it does the same thing as the outsider_in module use to do. I get that the new solution is a lot more flexible, but sometimes you just want a global role to work the same for an insider and an outsider.

Creating two group roles that sync wit a global role work, but it would be great if the was an option to set a role to outsider AND Insider.

Turns out, I'm very wrong in my earlier conclusion. Group 2.x has no need for the outsider-in module, but it does require some figuring out how the scopes work. I wouldn't say it is very intuitive and on a large project with lots of group and global roles, it will become a bit complicated, but with the individual, outsider and insider permission scopes it is very flexible.

I was able to configure my global role to sync with an insider role and it works as designed and more importantly, what I need for my use-case.

With a patch for this MR I still don't get the outsider permissions for group members.
I haven't put much time in figuring out why. For my use-case it is easier for now to patch the group module than figuring out why the module isn't working. As it is just 1 line of code I need to change so that is uses the insider AND outsider scope.

But having the module working is probably better as it is easier to toggle on/off and it doesn't seem likely this behavior will ever change in the group module.

We have been working with this outsider-in module for al longtime with Group v1, now that we are finally updating to v2 we hoped that this module wasn't needed anymore. So we disabled the module and... but outsider permissions are not looked at if you are a member of a group.

hasPermissionInGroup

// Then check their synchronized access depending on if they are a member.
if ($this->groupMembershipLoader->load($group, $account)) {
  $item = $calculated_permissions->getItem(PermissionScopeInterface::INSIDER_ID, $group->bundle());
}
else {
  $item = $calculated_permissions->getItem(PermissionScopeInterface::OUTSIDER_ID, $group->bundle());
 }

Which I guess makes sense for some projects, but in my project we have around 250 groups as we use them to relate departments to users. So adding a role for a user for all groups is a lot of work to manage.

I'll take a look at the merge request and hope that it helps for my project.

So this is becoming a conversation with myself. I mentioned that FileUploadResource is deprecated, that is not fully through. A lot of its methods are, but the class still sticks around for now and re-uses the FileUploadHandler. That is a good thing for my project as it extends the FileUploadResource. But I did confuse myself as I mention the FileUploadHandler and then my patch mainly touches the FileUploadResource. So this is as much a reminder for myself as anyone else that is in the unlucky situation to have to support multipart/formdata uploads (but I might be the only one).

I thought I tested the previous patch, but I most have had some uncommitted changes in my editor as it fails on the routing that now doesn't accept the format form anymore.

I've re-added the form to the requirements in FileUploadResource and to JSONAPI routing.

I Really want to embrace the new MR way of doing things, but there currently is a branch for 9.2.x or something and starting a new branch results in a page not found. So if someone can help with setting up a merge request for 10.3.x and/or 11.x.
Who knows, it might one day be implemented...

For now I've added a patch based on the 10.3 branch and tested it with 10.3.1.

The previous patch is for FileUploadResource which is deprecated in 10.3 and will be removed in 11.0.
FileUploadHandler will now be used: https://www.drupal.org/node/3402032 →

What that means for multipart/form-data upload, well my test doesn't fail but I do end up with a 0 bytes file.
So I need to debug and see why the file is empty.

r.van.doorn → created an issue.

We are testing version 2.1 of CKEditor Layouts and we ran into in something that I would describe as buggy behavior.
The focus for layout columns is not what you expect. When clicking on a column the column seems to become draggable for a short instance and then the editor decides what element it should place the cursor in. If it is the first column in a layout, this sort of works. If you click on the second column, the cursor jumps to the first 'editable' element. If there isn't any, again it sort of works and the cursor is placed inside the clicked column. If there is an editable element, the cursor jumps to that element.

To reproduce, add a paragraph with some text and then add a layout with multiple columns and try clicking on a second or third column inside the layout.

The fix seems simple though, just make the column an editable element instead of a container.

Added a new patch for Drupal 10.2.
Like I said in my previous comment, changed the return value of streamUploadData to return the path instead of the originalName.

I'll soon try to make some time to look into how drupal 10.3 affects this issue.

My multipart/form-data upload is still failing with the latest patch.
The Content-Disposition header with filename is now mandatory, which I can somewhat understand. It is just annoying that a different party is using our REST interface and they need to change their code.

But even with the Content-Disposition header set, the upload still fails on trying to move the temporary file. It claims it doesn't exist but that is because it uses the OriginalName to find the tmp file and not the actual path of the tmp file.

In FileUploadResource:
$temp_file_path = $this->streamUploadData($request);

The patch now returns
return basename($file->getClientOriginalName());

Shouldn't it return $file->getPathname();
I would say yes, but as I just glanced at the Symfony class I might be missing something.
It would be a simple fix, so I'm testing it and will upload a new patch soon.

I am a bit worried about Drupal 10.3 though, will look into that soon as it seems to refactor some relevant code and rerolling the patch will probably take a bit of time.

As described above, I've update the patch for 10.1 to check for 'form' format instead of the bin_multipart that was added in previous patches in this issue.

I think the patch needs to be updated, it uses getContentType() to check for bin_multipart. The getContentType is now deprecated and we need to use getContentTypeFormat. That uses format and has a fixed set of keys mapped to mime type.

static::$formats = [
  'html' => ['text/html', 'application/xhtml+xml'],
  'txt' => ['text/plain'],
  'js' => ['application/javascript', 'application/x-javascript', 'text/javascript'],
  'css' => ['text/css'],
  'json' => ['application/json', 'application/x-json'],
  'jsonld' => ['application/ld+json'],
  'xml' => ['text/xml', 'application/xml', 'application/x-xml'],
  'rdf' => ['application/rdf+xml'],
  'atom' => ['application/atom+xml'],
  'rss' => ['application/rss+xml'],
  'form' => ['application/x-www-form-urlencoded', 'multipart/form-data'],
];

So It will always return 'form' in this use-case, so I think we need to use the new method and replace checks for bin_multipart with form.
Since I'm running into this problem for my project I'll see I can put a new patch together.

We recently updated to PHP8.2 and to my surprise our site went down because of small error in this patch.

The error:
TypeError: str_replace(): Argument #3 ($subject) must be of type array|string, null given in str_replace() (regel 494 van /web/modules/contrib/matomo/matomo.module)

Which is where the get parameter 'search'. I've fixed it with a simple nullesce operator to return an array if null.

Looks good to me.

r.van.doorn → created an issue.

I'm running into this problem as well for my project, but weirdly enough not on all environments. So I'm nopt sure it I'm experiencing a different error but I do have a boolean field used to toggle other fields.

I get the following error in the log:
TypeError: array_keys(): Argument #1 ($array) must be of type array, null given in array_keys() (line 238 of /web/modules/contrib/field_states_ui/src/FieldStateManager.php)

So it breaks in generating a notice

if (!isset($target['#field_parents'])) {
  $parents = [];
  $this->logger->notice(
    t(
      '#field_parents key not found. This will may cause problems. If so, please report on the @link. For quickest resolution, please include the element details: @details',
      [
        '@link' => Link::fromTextAndUrl(
          t('Field States UI Issue Queue'),
          Url::fromUri('https://www.drupal.org/project/issues/field_states_ui')
        )->toString(),
        '@details' => var_export(array_keys($element[0]),TRUE),
      ]
    )
  )

I mean, I can easily just patch that the var_export isn't used if $element[0] is NULL and yes then the field_state works as expected.
But I'm guessing the real questions is why $element[0] is NULL in this context. I don't have an answer right now since I haven't debugged it (yet).