Closed (fixed)
Project:
Inline Entity Form
Version:
3.x-dev
Component:
Code
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
29 May 2020 at 21:45 UTC
Updated:
11 Feb 2024 at 22:59 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
kbriand commentedComment #3
geek-merlinThanks for bringing this up and the good debugging, code review and issue summary.
This goes into the right direction, but messing with #access has its traps (#access instanceof AccessResult).
I'm working on an abstraction currently.
Comment #4
geek-merlinComment #5
geek-merlinComment #6
geek-merlinComment #7
geek-merlinComment #8
geek-merlinHmm, issue forks are broken currently, so add a patch for now.
Comment #9
geek-merlinSo let's summarize.
- We have this specific issue, where IEF overwrites FieldPermissions's #access=AccessResultForbidden.
- Adding to #access securely turns out to have a lot of gotchas and should live in a library (for a first writeup see https://git.drupalcode.org/project/rat/-/blob/1.0.x/README.md).
- I created RenderArrayTool (RAT) for this and added it to fix this issue and all other access assignments.
- The problem of adding to #access applies in principle to each and every #access assignment, and we should fix all of them to better be safe than sorry.
The patch does exactly that, NR.
Although RAT accessAlter is test covered, a test for the case of this issue would be fine. (It need not be via FieldPermissions, a simple hardcoded TestAccessAlter module would be OK.)
Comment #10
chris matthews commentedIf anyone is interested our nonprofit would be happy to sponsor the time to help get this issue across the finish line so that Inline Entity Form can move to a stable 8.x-1.0 (or 2.0.0) release.
Comment #11
podarokneeds reroll
Comment #13
shivam_tiwari commentedComment #15
shivam_tiwari commentedComment #16
podarokMR!74 is in
tnx
Comment #17
podarokComment #19
geek-merlinComment #20
geek-merlinTODO: Add issue to bump php to 7.4 as the dep needs this.
Comment #21
geek-merlinComment #22
geek-merlinThanks to all the unconsented test rabbits...
Comment #24
geek-merlinComment #26
agoradesign commentedYou should add this dependency to the info file as well, otherwise it won't get automatically installed, when you enable IEF. imho we'd also need an update hook, checking if rat is already installed, otherwise enable it
Comment #27
geek-merlin@agoradesign You are so right. And i was so wrong when i thought that having had that some months in that 2 branch would have been test enough. Reverting and rolling a release.
Comment #30
agoradesign commentedPS: aaaaaaaaaaaaaaa I'm sorry, I've just read trough the related issue #3362832: Dependency on RenderArrayTool, and now know that the rat module is more a library than a real Drupal module, so it would technically work, without enabling the module, I guess. However, this would be a very unconventional approach for a Drupal module dependency.
I have done manual code review before updating to rc18, instead of just tryin' - and that new dependency, that wasn't even declared in info file, nor installed in update hook, simply refrained me from even trying to update.
So my conclusion: rc18 wasn't that "broken" - or better BC-breaking - as I thought, but I don't really like the approach of adding a Drupal module dependency without needing to install it - so I highly appreciate the revert in rc19 :-)
Comment #31
geek-merlin@agoradesign Oh! Then this was a big misunderstanding, i assumed you checked.
Nevermind. Better safe than sorry. Yes RAT is a library, and libraries CAN be hosted on d.o.
And i can imagine you may even like the library.
Comment #32
agoradesign commentedyes, it actually was so :( but you're right - better safe than sorry :)
I'll have a look for sure - if it will be re-added to IEF again, it'll be present in any of my projects anyway :D
Comment #34
geek-merlinBack to fixed.