I have created a custom list, in which I am not using any Site Columns or Site Content Types; I started with the OOTB Item content type and added various custom columns to the list using the "Create Column" command.
One of the columns I created is a lookup column, and I selected several other columns from the source list under "show these additional fields" when I set it up.
I did enable "allow management of content types" on the list, but only to set some columns to Hidden - I'll be using them in a workflow and displaying them in some list views, but don't want the users editing them directly.
As I was checking that everything was in place, I realized I needed one more column from the source list to attach to the lookup. So I edited the primary lookup column and checked the box for the additional column that I had previously omitted. But when I return to the list settings page I see that this new column is not associated with my Item content type:
Likewise, when I pull up the display form for an item, the last additional column that I added is not displayed.
I can add the latter column to a list view, and it does display there correctly, but I cannot find any easy way to add it to the Item content type, or otherwise get it to show up on the OOTB DisplayForm.
While I did figure out two workarounds - remove the primary lookup column from the list entirely, then add it back in, selecting all additional columns at once; or save the list as a template, then create a new list from that template - each of those would bring their own problems if this situation were to come up on a list filled with data, instead of an empty one that I'm just now creating.
Is there any way to force an additional-column, which wasn't selected when the lookup column was first setup, to join it's fellow additional-columns in the DisplayForm when I add it later, without removing and recreating the lookup column or creating a whole new list?
I have SCA privileges on the site, and SharePoint Designer, but would prefer a no-code solution, if possible, because I know that frequently, once you use SPD to fix something, you're either completely unable to subsequently edit that content in the browser, or you can, but doing so wipes out the fix and then you have to recreate it in SPD again. My organization strongly encourages minimizing SPD customizations and application of custom code, due to the potential impact to future support personnel.