#API-First Initiative

Adding the related issue I noted in #35. The steps to reproduce on that one don't involve jsonapi which may simplify things.

This looks very much related to 🐛 Access cacheability is not correct when "view own unpublished content" is in use Needs work . Actually they looks like dupes. Should probably close that one since it's way more recent. There's a patch on that one that might be worth reviewing though.

I found some nice related issues while reporting that one. In particular, I felt like the real solution was to be found in 📌 Introduce entity permission providers Needs work .

So MR #8157 currently implements the suggested approach from [#2982770#comment-12669550] but it only adds cache per user when there are no node_grants implementation in the system. It should be sufficient because when there are node_grants implementations then user.node_grants:view cache context gets bubbled up.

This might be better as a separate controller?

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.

Simple rebase, nothing changed but the deprecation message. Updated the CR and target for MR. Think those are small anough changes for a direct RTBC

bbrala → changed the visibility of the branch 3100732-11.x to hidden.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Hi Folks, unfortunately we've missed the window for 11.0.x and 10.3.x now.
I think we need to re-do this 10.4.x as the 'from' in the deprecation notice and 12.0.x for removal.
The only consolation is at least then there's only one MR.

Thanks for all the effort here.