New DevPortal - style issues with unresoved style/colors dependencies in button styles

[AnRei123]

Bug description

Deletion/renaming of an existing color item that is referenced in a button style hinders the users to apply new colors to a button style element, prevents the display of the button shape on the pages and hinders the user to apply inline colors to a dedicated text section on a page.

Reproduction steps

1. Go to 'Styles' configuration page of the New DevPortal from the API Management page
2. Reset the portal
3. Click on a 'Button' entry in the Buttons section and click on the item 'Edit variation' icon
4. Change some buttons settings including the Background color and text color
5. Save the changes in the DevPortal with the 'Save' icon
6. Close the and reopen the DevPortal
7. Go to the 'COLORS' section
8. Delete the color from the COLORS section that had been applied to the button as background and/or text color.
9. Save the changes in the DevPortal with the 'Save' icon
10. Close and reopen the DevPortal
11. Go to the Buttons section in the styles configuration page
12. ALL buttons are disp in black and white only irrespective if some of the applied colors are still available
13. Try to fix the issue by applying new existing text and background colors to all the buttons
14. Applied colors are not reflected in the preview view and not on any page. Still colors are displayed in black and white
15. Go to the 'Home' page and apply an existing language to a word in a text block
16. The applied color is not reflecting in the page preview. The word color hasn´t changed
17. Download the data. json file and substitute the colors and button section in the Styles section with the data from the data.json file from a resetted page
18. Upload the partially resetted data.json file.
19. Go to the 'Buttons' styles section
20. Apply different colors to the button styles
21. Save the DevPortal
22. Close and reopen the DevPortal
23. Go to the 'Buttons' section
24. Changed colors are displayed correctly - partially reset and newly applied colors fixed the issue -

Expected behavior

• When removing a referenced style a message pops up and lists all the dependencies that need to be resolved before removing a color style.
• When removing a referenced style all the dependent styles use a default setting as a fall-back (e.g. an element that never can be changed)
• When renaming a referenced style element, references in other style elements are correctly updated before saving is possible.
• Even if references for one button cannot been resolved correctly, other button items are still displayed correctly. (Important for a root cause analysis)
• Even if color references in buttons cannot correctly been resolved, inline formatting to color text shall be still possible
• Even if colors are removed or names of color items are changed, the missmatch should be fixable by applying a new languages w/o the need of a partial reset

Is your portal managed or self-hosted?

Managed

Release tag or commit SHA (if using self-hosted version)

n.a.

API Management service name

problem occurs for all our instances of the API management

Environment

• Operating system: Windows 10
• Browser: Firefox (68.4.2esr (32-bit))or Chrome (Version 79.0.3945.130 (Offizieller Build) (64-Bit))

Attachments: data-json.zip

[azaslonov]

Hi @AnRei123,

I could not reproduce all the steps (maybe I'm reading it wrong). However, here are some comments for Expected behavior, maybe this can explain some of the things:

• When removing a referenced style a message pops up and lists all the dependencies that need to be resolved before removing a color style.

There is a message already:

• When removing a referenced style all the dependent styles use a default setting as a fall-back (e.g. an element that never can be changed)

Right, this is exactly what happens. However, the styling system has a concept of inheritance which is very similar to the way Cascade Style Sheets (CSS) rules work. Almost every property of a component inherits its values from a default component unless it is specifically set/overwritten in a variation (applicable to both global and local ones). In your case I believe you have removed the color used by Default button variation, that's why all the rest button (those not having an override) turned black'n'white too.

Another thing that we might need to do is to introduce more default, non-deletable styles (like there is one for text). I filed a separate issue for that.

• When renaming a referenced style element, references in other style elements are correctly updated before saving is possible.

Yes, this is how it is designed. Every style is referenced just by a key that never changes, so that all modifications to style are correctly resolved during style generation.

• Even if references for one button cannot been resolved correctly, other button items are still displayed correctly. (Important for a root cause analysis)

As described above, that is true for all the override styles, but not for inherited ones.

• Even if color references in buttons cannot correctly been resolved, inline formatting to color text shall be still possible

Same as above.

• Even if colors are removed or names of color items are changed, the mismatch should be fixable by applying a new languages w/o the need of a partial reset

If I understand it correctly, you want a kind of step (part of delete process) where you can choose a substitute?

[azaslonov]

Closing due to inactivity. Please feel free to re-open shall you need further assistance.