IBPL fields are extremely useful and almost a necessity for us because our list values are constantly changing or being updated for multiple domains.
These fields work very well in the "Item View" but when used on a Node while editing in the "Document View", the fields seem to be making the entire item uneditable.
If the column for the IBPL field is visible in the "Document View" and a user selects a value for the field and saves, that row becomes uneditable until the column is removed from the "Document View." All other rows that do not have values set for the "IBPL" field remain editable until a value is set for that field (in which case these rows also become uneditable).
Take a look at the images below:
This is causing major problems for us because using static pick lists requires major maintenance from admins and dynamic IBPL's are just not supported in the document view as we expect. Since you can't make FVA's from IBPL's, that's also not an option. So... what's the solution? Because we REALLY need one.
I'm pretty sure you are seeing a defect we identified;
It looks the same to me anyway, given the scenario you describe. As Lance suggested, I would make sure to open a Support case for this, and make sure you're hooked up with that defect SPR, and find out the current state of it.
No it's definitely not the same in any way.
The defect you identified refers to the "Multiple Line Editing" feature that was added 10.7 I believe.
This issue has nothing to do with that feature - that feature is NOT enabled when I am facing this issue.
To reiterate - the issue ONLY occurs if an IBPL field is a visible column and has been filled in for a particular row.
If the field is populated, that row becomes uneditable on saving. If the column is made to be invisible, the row becomes editable again.. so I deduce that the clear cause is IBPL fields not being supported by the Document View as expected.
I have not created a support ticket as of now but if there are no solutions available through the community I will go ahead and create one.
That article wording needs to be updated to make it clearer, as the defect SPR can be hit even when you're not using multi-edit. It just seems to surface more often when multi-edit is used.
So it does look like the same issue. Yes, please open a Support case.
Raised a Support case as you indicated.
Seems bizarre that a function that's not enabled can cause a particular type of field to make Nodes uneditable.
What's the relation?
Multi-edit does not cause this issue at all; it's just that it seems to surface more, when it is used. The cause seems to be more of some timing hole, which given the nature of multi-edit (when it is used) is probably easier to hit in that scenario.