Field is locked for adding a new content type that should be available for reference

Yeah the locking of the settings after a node is posted is becoming more and more of a nuisance the longer I work with it. There should be a feature to get around this for people who know what they're doing. I'm not just talking about this module, but fields in general.

I also need to be able to add new allowed node types to an existing node reference field. I understand you cannot unselect node types for which data is present in the database, but it must be possible to add new types.

For example: a club that organizes different types of events: star gazing evening and lecture. I created two node types for these event types. Members of the club can write a report about an event so they must be able to select which event the report is about. A node reference field to specify this was added to the blog article type. The allowed node types are initially set to the two types above. If the club wants to organize a different type of event (e.g. museum visit) I need to create a new node type, but I cannot change the node reference of the blog article type to also include the new event.

ugh, this is a really big pain in the ass. if anyone has come up with a workaround please let me know.

Workarounds include removing the $has_data stuff from the module, or using hook_form_alter or hook_form_FORM_ID_alter to change the #disabled state of those form elements.

If you can uncheck a content type for which data is in the database just by modifying the client-side form, then there is something wrong with the server-side validation of the submitted form. And this should be reported as a bug.

The ideal situation would be:

• On form creation only enable the checkboxes for content types which do not have nodes with references to them yet. This includes both previously selected content types and new content types.
• On form submission only process checkboxes for content types which do not have nodes with references to them yet. This prevents deselection of content types with nodes that are already referenced.

I am currently looking into it, but I am new to Drupal so I am still trying to figure out what the best way is to determine which content types already have references pointing to their nodes. Should I use SelectQuery or EntityFieldQuery? And how do I determine the table name containing the data for this field? Simply concatenate the field name to field_data_?

The field probably has to be changed from a single checkboxes field to a checkbox field for each content type. And the message indicating that the settings cannot be changed should probably be changed to state that some settings cannot be changed.

The attached patch enables the addition of new content types to the list of referenceable types of a node reference. If the SQL storage module is used, it also allows deselection of content types that have no references to them at this moment.

Please note the following:

• The assumption is made that when the SQL storage module is used for the field, the nodes will also be available in the SQL database.
• To determine the actually referenced node types when using the SQL storage module, only the current revisions of nodes are considered. This means restoration of an older revision may lead to references to types that are no longer allowed. The code can easily be changed to considering all revisions though.
• If a storage module other than the SQL storage module is used and data is present, you will be able to select new content types as allowed types. But you won't be able to deselect those content types after you have submitted the form, even if you did not set a reference to nodes of those content types. In other words: you won't be able to undo a selection in this case, so be careful when editing the field settings.

@j.stuyts: Thanks for working on this. However, your patch seems to contain only binary cruft ? :-)

Agreed that EntityFieldQuery is of no help here (it cannot check the type of referenced nodes), so a best-effort reasoning in the case of sql_storage is the best we could do.

However :
- The same problem exists on user_reference fields: cannot check a new role or modify the 'selectable user states' checkboxes once there is data. Those two places would need the same kind of fix.
- To be honest, I'm not even sure we really want to enforce those checks. We didn't when noderef lived in CCK. If you uncheck a node type for which there are referenced nodes, the now "invalid" values stay around, and will cause a validation error next time the referring node is edited. I don't think this raised major complaints since CCK D4.7.

This "invalid data stays around" behavior is unavoidable when the list of 'referenceable nodes' is defined by a View instead of by node type (which is the last missing feature in the D7 version), and we don't really care. Similarly, if you change the 'min / max values' of a number field, existing values can become suddenly invalid, and we don't do anything about it. We don't do ad-hoc mass data updating. CCK never provided the required scaffholding, and D7 Field API did not bring any progress on that regard (quite the opposite in fact).

OTOH, not being able to remove a node type from the list of referenceable types until you have removed all the 'soon invalid' values from all existing nodes (which would be the result of the approach in #7) can be a massive PITA while setting up a site.

So for now, I fixed the (quite serious) bug of not being able to reference newly-created node types or user roles, by just removing the #disabled attribute from the checkboxes.
Committed the attached patch.

Marking as "fixed" for now. I don't want to sound like I'm ditching the work you did, @j.stuyts, but the original bug is annoying enough that we need to fix it asap. Another issue can be opened for the "referencial integrity" consequences, but as explained above, I'm afraid there's not much that can be done about that.

I'm fine with removing the restriction altogether. I don't mind still having nodes referring to types that are no longer allowed.

I will take a look at how I create patches. I figured git would do things correctly automatically, but apparently it doesn't.

Any update on this? I need to change some SELECT list values in my select list field. Drupal won't let me change it!

This is related to Drupal core. You will see the same restriction on all fields, not just reference field.

http://drupal.org/node/1378894