Conditioning Fragment inclusion on Profile discards layout customizations
Description
When DLM audience evaluators exclude fragments depending upon the currently selected profile, user layout customizations to excluded fragments are eagerly cleaned up (discarded) by DLM. However, for use cases involving supporting multiple profiles (e.g., opt-in or opt-out of a new profile via request parameter at login / SessionAttributeProfileMapper), these layout customizations may still be valued for application to future sessions under the relevant profile even though they are not applicable to the current session's profile selection.
The fix: Make DLM less over-eager to discard user layout customizations in this way, or something.
It's kind of an interesting problem, differentiating layout customizations that will never again be relevant and so should be discarded, vs layout customizations that may again become relevant.
Might be a matter of queueing layout customizations for future deletion after a long enough grace period, pulling them from the queue if they become relevant again (are applicable).
When DLM audience evaluators exclude fragments depending upon the currently selected profile, user layout customizations to excluded fragments are eagerly cleaned up (discarded) by DLM. However, for use cases involving supporting multiple profiles (e.g., opt-in or opt-out of a new profile via request parameter at login / SessionAttributeProfileMapper), these layout customizations may still be valued for application to future sessions under the relevant profile even though they are not applicable to the current session's profile selection.
The fix: Make DLM less over-eager to discard user layout customizations in this way, or something.
It's kind of an interesting problem, differentiating layout customizations that will never again be relevant and so should be discarded, vs layout customizations that may again become relevant.