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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

keithm’s picture

Status: Active » Needs review
FileSize
4.08 KB

Patch attached.

sun’s picture

Thanks!

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.

keithm’s picture

@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.

sun’s picture

Wasn'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?

keithm’s picture

Status: Needs review » Needs work

Had 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:

5:17pmerlinofchaos:keithm: It seems like it's really a question about field api and where you get information that you pass to Views.
5:17pmerlinofchaos: keithm: I don't think Views cares where you get it.

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.

sun’s picture

keithm’s picture

That makes sense. Thanks for posting it.

keithm’s picture

Status: Needs work » Needs review
FileSize
6.99 KB

Given 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.

keithm’s picture

#8 with corrected @see Doxygen format.

keithm’s picture

Status: Needs review » Fixed

Automatically closed -- issue fixed for 2 weeks with no activity.