Hi, I'm not sure if I'm missing something to get this to work.
The module works great when it is applied to a basic content type.

I'm trying to use this module with the Inline entity form widget, I have a Team content type and a Project content type.
The Team content type has to entity references, Role and User, User is dependent on Role. Works great!
Until I use a entity reference inside of the Project content type, I'm using an entity reference with the Inline entity form - multiple values and referencing the Team content type.
This messes everything up, the Team content type does show up, but the User drop down is no longer dependent on the Roles.
I've also try this with the Field Collections module and it has the same issues.

Any help would be really appreciated.

Thanks,
Stephen

Comments

sskully created an issue. See original summary.

joachim’s picture

Version: 7.x-1.6 » 7.x-1.x-dev
Category: Bug report » Feature request
Issue tags: -inline entity form issue

This currently only works with the core widgets.

sskully’s picture

Hi,
Is there plans to have it work with Field Collections or Inline entity forms?

Thanks,
Stephen

joachim’s picture

It's not something I plan on working on personally, but if someone posts a patch, I'll review it.

Vector-’s picture

Here's a patch that (if I've actually rerolled it correctly...) should get limiting fields working inside of Inline Entity Forms, though I don't think it will support limiting fields inside an IEF from current selections on the host entity, and I'm not entirely sure it won't break things elsewhere.

The approach is a bit messy and heavy handed as it's a hasty reroll that includes some work in progress and things needed to support other patches that aren't entirely central to solving the problems with limiting inside IEFs, such as:

  • storing path nested settings is probably not the best way to avoid collisions
  • should use a helper to fetch settings path if we're going to use that method
  • detecting IEF form-ception in progress could probably use some work
  • loading/storing the wrapper in the form is needed for multiple replacements
  • cloning $entity seems like a good idea and fixes some issues I was having, but could it have side effects?
  • I don't think (re)storing the original entity when cloning is necessary, but it shouldn't hurt to be explicit there?

This could probably be adapted with a few changes from #1624378-12: Limiting options doesn't work with field collections to get things working for Field Collection. Using a similar technique to sniff out already assigned selector IDs could probably get things working with Field Group Multiple (and Multi Select?) too. Crossing form boundaries during IEF form-ception might be a bit more tricky as you'd potentially need to spoof several entities (and probably add some new options?), but the context should be available in $form_state to do so.

Vector-’s picture

On my setup the rebuilt entity seems to be available at that path in $form_state['values'] even when IEF isn't involved at all.

Here's a quick update to try accounting for that to cut down on entity rebuilds. Not sure if trying to take the entity from $form_state['values'] when not necessary for IEF might have unwanted side effects or added dependencies though.