What is the version of xEdit you are using?
SF1Edit 4.1.4w EXTREMELY EXPERIMENTAL (RC6 for 4.1.5) x64 (CEBBD766)
Describe the bug
If you apply a blank filter to the plugins so that xEdit will conflict colorize them, it does so, but if you remove and re-apply the filter, it does not re-colorize new or resolved conflicts - it just reuses the previous colors.
To reproduce
- Load all plugins
- Apply a filter with no filters enabled, so that all xEdit does is apply conflict coloring.
- Resolve or create a conflict that changes the color of a form - it won't change the tree color (which is known), but it does update the record colors in the form itself.
- Clear the existing filter
- Re-apply the filter you applied in step 2
- Go to the record that you modified in step 3
- Observe that the tree color coding for the plugin or tree records have not changed to reflect the new conflict status, even though the form values are still displaying the correct color.
Expected behavior
The tree coloring should update after a filter refresh to show accurate conflict coloring - optimally it would update inline as conflicts are adjusted (as xEdit used to do), but I understand that is a project for later.
Screenshots
N/A
Additional context
N/A
What is the version of xEdit you are using?
SF1Edit 4.1.4w EXTREMELY EXPERIMENTAL (RC6 for 4.1.5) x64 (CEBBD766)
Describe the bug
If you apply a blank filter to the plugins so that xEdit will conflict colorize them, it does so, but if you remove and re-apply the filter, it does not re-colorize new or resolved conflicts - it just reuses the previous colors.
To reproduce
Expected behavior
The tree coloring should update after a filter refresh to show accurate conflict coloring - optimally it would update inline as conflicts are adjusted (as xEdit used to do), but I understand that is a project for later.
Screenshots
N/A
Additional context
N/A