Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Global field settings apply to all instances of a field. They are mostly intended for field storage schema-level things that cannot be changed later on; e.g., when a field setting would lead to additional field schema columns or different schema column types.
Compared to that, instance settings only apply to a single instance of a field. Having a viewfield with multiple instances and the desire to have different allowed values on each of them isn't really uncommon.
Comments
Comment #1
keithm CreditAttribution: keithm commentedPatch attached.
Comment #2
sunThanks!
mmm, though perhaps I'm mistaken with this -- http://api.drupal.org/api/drupal/modules--field--field.api.php/function/...
We need to double-check that, perhaps talk to @merlinofchaos and other field/views developers.
Comment #3
keithm CreditAttribution: keithm commented@sun: Wondering if you have gotten any more information on this, especially the "settings that Views needs to use across field instances (for example, the list of allowed values)" part.
At a usage level, instance level settings obviously offer greater flexibility, but potentially at the cost of having to respecify allowed values for each instance in the case where the settings are identical for all instances. In the absence of a good set of use cases, this might be a strong enough argument to go the instance settings route.
Comment #4
sunWasn't able to ping anyone yet. Can you also try to reach out to @merlinofchaos or @dereine for the Views-related part of the question, and possibly @chx, @yched, and others for the field related part?
Comment #5
keithm CreditAttribution: keithm commentedHad a quick IRC with merlinofchaos. When I asked about 'Notable exceptions: settings acting on the schema definition, or settings that Views needs to use across field instances (for example, the list of allowed values).' from http://api.drupal.org/api/drupal/modules--field--field.api.php/function/..., he seemed not to be concerned:
I'm now thinking that the exception comment above pertains to data that views needs to either drive its UI or render the view itself. Our allowed_views list doesn't intersect with either case (it merely supplies the view/display names well before rendering time), so I think Views is agnostic on this field/instance question.
I'll continue to follow up on the fields part.
BTW I forgot to update the D6 migration in #1 so it still needs work.
Comment #6
sunCreated #1286658: Clarify field settings vs. instance settings
Comment #7
keithm CreditAttribution: keithm commentedThat makes sense. Thanks for posting it.
Comment #8
keithm CreditAttribution: keithm commentedGiven the resolution in #1286658: Clarify field settings vs. instance settings, going ahead with this. Rerolled patch for latest version, and updated content migration code for new settings.
Comment #9
keithm CreditAttribution: keithm commented#8 with corrected @see Doxygen format.
Comment #10
keithm CreditAttribution: keithm commentedCommitted: http://drupalcode.org/project/viewfield.git/commit/d3a1888.