cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Including and utilizing IBPL field on a Node in the Document View causes the Node to not load

Newbie

Including and utilizing IBPL field on a Node in the Document View causes the Node to not load

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:

  • In Image 1, you can clearly see that Row 3 (highlighted) is uneditable - the error is that Integrity has not finished loading all the required fields (spoiler: it never "finishes")
  • Row 1 and Row 2 (or any row that has a value selected and applied for Column/Field "Part IBPL") is also uneditable

IBPLonNode 1.PNG

  • In Image 2, you can see that Row 3 is now editable after the "Part IBPL" column is hidden

IBPLonNode 2.PNG

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.

6 REPLIES 6

Re: Including and utilizing IBPL field on a Node in the Document View causes the Node to not load

Have you opened a support ticket for this?

Re: Including and utilizing IBPL field on a Node in the Document View causes the Node to not load

Hi Sourabh,

I'm pretty sure you are seeing a defect we identified;

https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS239655&lang=en_US

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.

Re: Including and utilizing IBPL field on a Node in the Document View causes the Node to not load

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.

Re: Including and utilizing IBPL field on a Node in the Document View causes the Node to not load

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.

Re: Including and utilizing IBPL field on a Node in the Document View causes the Node to not load

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?

Re: Including and utilizing IBPL field on a Node in the Document View causes the Node to not load

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.

Announcements