This module has resolved my use-case of separate access controls per media type.
- Access permission independent of media usage
- Access permission based on media usage
It is definitely useful and I hope it will either make it's way into core, or will continue to be available for D11
https://www.drupal.org/project/drupal/issues/2904842
🐛
Make private file access handling respect the full entity reference chain
Postponed
Would love to have additional information from the maintainer.
Would like to echo @teknocat.
Ran into this issue after reading through the file module overview and wrongly inferring the 'new & improved' media would behave similarly.
The suggested media_private_access covered my use-case and helped intuitively explain the issue of
- Media entity permissions independent of media usage
- Media entity permission based on media usage
Is there any chance of the per media type access drop-down making it's way into core?
Hi amritsingh09,
Thanks for you work, I have applied the fix on the latest version.
I can confirm this still works and does what is expected.
The module maintainers should merge this when possible.
Hi ollaankoodeis,
Thanks for your fix, I also ran into this issue and your patch fixed the issue.
The module maintainers should really try to merge this fix ASAP, as the extension is rendered unusable otherwise.
Unless this is no longer being maintained?
Hi @Jayesh_Vijay,
I am also running into this issue with credentials expiring due to the change in the fetch URL structure.
I'm keen to get this resolved, and am happy to test any changes you made?
I've checked through the branch 3465324--token-refresh but can't see any commits relating to the access token.
Are you still looking at solving this?
Wow, feels great to run up against an issue and see it being resolved in real time.
Patch #270 solves the issue for me as well on version 2.0.9, thanks.
Can confirm also experiencing this issue on a site when using Chrome + CF.
But works fine for the same site with Firefox + CF.
@mnsmithuk
Thanks so much for posting your experience with the failing migration:import.
I was having this exact issue after running the initial migration, then making changes different elements of the shop and then trying to run the upgrade_uc7_payment migration with --update flag (failing to import all the new payments for orders).
The issue ended up being a change to the Payment Processors.
To resolve it
- I rolled back the payment processors migration job
- Cleared all the caches
- Re-ran the payment processor migration
- Edited each payment processor entry created and saved the node
- After saving all the nodes re-ran the payments job
Some config is changed the first time you save the node that allows the migration to 'find' it now.
This got it working again and got the D10 unblocked.
Hope this helps someone facing the same issue.
Also ran into this issue when running 'migration:import --update' after adding the location_migration module and was having the same issue despite running the 'required migrations'. The #13 patch worked as described, thanks @huzooka.
Is there anything missing that is holding this back from being merged?
Also ran into this issue when running 'migration:import --update' after adding the location_migration module and was having the same issue despite running the 'required migrations'. The #13 patch worked as described, thanks @kenwest.
Is there any chance we could get the original patch merged? Say if we add the patch against this ticket?
m_hobby → created an issue.
m_hobby → created an issue.
@Liam Morland, thanks #10 in my case resolves the bug.
@smustgrave, is there anything else (test coverage?) that is needed to get this issue across the line?
Many thanks.
Hi, would like to echo @Giuseppe87.
I have a similar setup with an ajax flag/unflag, and after the last set of updates to the flag/flag Bookmark.
I have been facing 'csrf_token' URL query argument is invalid'.
Both solutions mentioned in #21 work (in case someone else is having this issue).
Thanks @COBadger & @cslevy in both cases your answers work, is there something we can do (maybe just linking to this issue) that can help reduce any time for future people searching for a fix?
I have also tested #17, it does exactly what I need. Thanks.
Can confirm #9 solves the error performing delete operations from the configuration page.