Should the service fields selected only be shown in the expandable area of a service in the admin/client interface, or should there be a tab when managing the service that lists them instead (or both)?

I think the WYSIWYG solution is too complex. Would be much simpler if, next to each service field, we have the option (select menu):

[ Do not Display ]
[ Display to Staff ]
[ Display to Staff and Client ]
[ Display to Client ]

Then we just build the table in the expandable area using a simple table. Yes, this means you can't add fancy HTML like links, but that's not needed most of the time. The universal module is not a replacement for a dedicated module.

Not even sure [ Display to Client ] is necessary, since how often do you want to show something to the client that you don't want staff to see?

I agree

• Do not display
• Display to Staff Only
• Display to Staff and Client

The simplification of setting service fields for display is nice, but my original question was in regards to where to display the fields. The task suggests the expandable service row section. Is that preferable over a dedicated tab when managing the service? The expandable row tends to get overlooked.

I assume, also, that when displaying the service fields, we will show the selected option LABEL rather than the selected option VALUE, such as with drop-down fields, correct? Is there any case where we might want to include other information, such as the selected option value, or the service field name?

I think it would be nice to show the fields when managing the service as well.

When displayed in a table, the label becomes the column name, the service field value becomes the value in the cell, except in the case of select, radio, and checkbox field types. Then we need to parse the options and display the selected name for the value.

Someone recently asked for this and they want to include links/data that is not included in the service field. I think if we implement this we should allow HTML, the person can customize it how they want and embed links or other content. Not necessary to have a WYSIWYG editor, a textarea is fine. Maybe we put an example code in the documentation. Tags of package and service fields should be available.