Add a required indicator for horizontal tab elements that contain a required field

Hey Dave,

We already did that in last sprint. I will check this again to see why it does not work for you, but we did it on server side in stead of client. I will keep you informed.

Stalski

Moved vertical tabs, horizontal tabs and accordion required fields to javascript, removing the code for required fields server-side.
I gave an extra context of view mode to the js hook so we can only trigger this for field groups that are in the form context.
Patch is attached. Please test.

Both Drupal.FieldGroup.Effects.processHtabs and Drupal.FieldGroup.Effects.processTabs use the same pattern. I'd create a helper function and maybe try to use it also in Drupal.FieldGroup.Effects.processAccordion ? Also with find('strong:first') - what if someone overrides the default theming, will that still work ?

For the strong:first: It is possible that another contrib or custom module overrides the js function "Drupal.theme.prototype.verticalTab" .
The only solution here, is to let the contrib/custom module override a prototype of ours.
So the javascript hook function "Drupal.FieldGroup.Effects.process[FORMATTER_TYPE]" should be a prototype as well.
I am working on that now.

The refactoring to use a helper function would only make sense for the Htabs and the Tabs. But even here, knowing that there will only be two (as you have only vertical/horizontal as a pair), i think we can postpone the refactoring. Passing by a couple of jquery.selectors does not feel good.

thx for the review. Again a big issue raised ;)

- reviews make us better -

The required asterix is committed.

The discussion of field_group having horizontal tabs library is discussed in [#/1036184]

Reopening - currently don't like the the system settings screen, we could make this prettier. Don't close so fast so I can track more easily too :)

Edit

we'll discuss this tomorrow, imo the system settings screen is horrible UX, let's fix that.

Well funny you thing of that too. I was creating use cases to see how far everything could differ between node types (entity types), bundles or view modes.
My conclusion was that you this setting can't be global.
1) Each form should be able to be set as "required fields in group". This will not be easy on a form.
2) Another option, is to even make it configurable on a fieldgroup formatter basis, but that might be overkill. (but simpler to store in our own database table)

I prefer per bundle and entity type. I 'll take this with me in our discussion tomorrow ;)

My two cents: a simple checkbox which adds a class and the javascript looks for that class. We'll see.

The cleanest way will be to do it in fieldgroup is to have storage on the field_groups. Maybe a js-toggle in backend which adds a extra class. This will implicate that people can dish that class if they don't understand why it's there.
Guidelines will be needed there.
TODO:
- Add a control in the fields/display UI screens to opt for required fields in fieldgroup indicators, adding a class to the fieldgroup wrapper
- Refactor the javascript hook implementations so that the selectors matches the new added class.

This is refactored and committed.
There is no upgrade path for the old behavior. We can set the required field group indicator per field group. At front the javascript handler will check if it's needed or not.

Fixed the last bug on multiple nested fieldsets on one page.