Closed AnRei123 closed 4 years ago
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?
Closing due to inactivity. Please feel free to re-open shall you need further assistance.
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
Expected behavior
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
Attachments: data-json.zip