This aims to enhance the data provider restriction panel with toggles, default buttons, and a ternary checkbox (indeterminate, checked, unchecked states). Unlike the current logic, both whitelisting and blacklisting are employed for greater flexibility. See issue
1352, #1004
Note: The previous, more basic attempt (without whitelisting/tristate and default only applying to future data providers and servers) is located in dppolicy. Perhaps, somehow, it can be optimized by incorporating more convoluted logic (keeping default exclusion list rather than black or white list). However, tristate/black-and-white lists seem more efficient in terms of storage space. Additionally, maintaining the exclusion list in a meaningful and robust fashion might require more precautions for exceptions/failures, etc. (which would need further discussion). In particular when policy reversal takes place, in my opinion the exclusion list be replaced with it's compliment. I am concerned that the resulting exclusion logic and code would be even more confusing than the presently suggested ternary approach.
This aims to enhance the data provider restriction panel with toggles, default buttons, and a ternary checkbox (indeterminate, checked, unchecked states). Unlike the current logic, both whitelisting and blacklisting are employed for greater flexibility. See issue
1352, #1004
Note: The previous, more basic attempt (without whitelisting/tristate and default only applying to future data providers and servers) is located in dppolicy. Perhaps, somehow, it can be optimized by incorporating more convoluted logic (keeping default exclusion list rather than black or white list). However, tristate/black-and-white lists seem more efficient in terms of storage space. Additionally, maintaining the exclusion list in a meaningful and robust fashion might require more precautions for exceptions/failures, etc. (which would need further discussion). In particular when policy reversal takes place, in my opinion the exclusion list be replaced with it's compliment. I am concerned that the resulting exclusion logic and code would be even more confusing than the presently suggested ternary approach.