You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now we have a 'super' validation set 'RSR' which applies by default to all projects in RSR. This is a collection of mandatory fields and hidden fields. The fields that are not flagged up there are 'nice to have'.
In addition to that, there is a possibility to create a custom validation set based on organisation's needs, for example NLR validation set. In a custom validation set, you can only hide fields which are already hidden and are not mandatory in 'RSR' validation set. It makes a lot of sense to cross-check for mandatory fields and not allow hiding them in any custom validation set. However, when it comes to hiding fields which are not mandatory (but also not hidden) in RSR validation set, the logic gets a bit vague.
We should think about the best way to allow partners hide fields, which are not flagged as mandatory in RSR validation set. Some partners complain that we promise them a possibility of having their own validation set, but at the same time do not allow to hide fields which are not even mandatory.
@punchagan, we already talked at length about it and you said you'd give it more thought. Please comment, if you have some further thoughts on that.
Mandatory field: A field becomes mandatory if even one of the validation set marks it as mandatory
Hidden field: A field gets hidden in the project editor only if all the validation sets mark it as hidden.
We don't wish to change the RSR validation set, because every project uses it. Making a field hidden, for example, would hide it for all the projects that only use the RSR validation set (a lot of projects!). Even then, how was it decided (and in future how do we decide) that a field should be hidden/mandatory in RSR or not?
The logic for the hidden field could be changed to be similar to the mandatory field logic, i.e., a field becomes hidden if it is marked as hidden in even one of the validation sets. But, this would mean the current custom validation sets would need to be modified to be able to explicitly state that a field should be shown (3rd option, along with hidden and mandatory). This would make the logic very simple and explicit, but would need some work modifying the existing validation sets.
We could also considering a third option -- "super" hide -- alongside the existing hidden and mandatory options. The logic for the hidden option would remain the same -- a field is hidden if it is marked as hidden in all validations. But, additionally, it is also hidden if any of the validation set "super" hides it, irrespective of whether or not other validation sets hide it. "Super"-hide would not be able to hide a field marked as mandatory by another validation set.
Right now we have a 'super' validation set 'RSR' which applies by default to all projects in RSR. This is a collection of mandatory fields and hidden fields. The fields that are not flagged up there are 'nice to have'.
In addition to that, there is a possibility to create a custom validation set based on organisation's needs, for example NLR validation set. In a custom validation set, you can only hide fields which are already hidden and are not mandatory in 'RSR' validation set. It makes a lot of sense to cross-check for mandatory fields and not allow hiding them in any custom validation set. However, when it comes to hiding fields which are not mandatory (but also not hidden) in RSR validation set, the logic gets a bit vague.
We should think about the best way to allow partners hide fields, which are not flagged as mandatory in RSR validation set. Some partners complain that we promise them a possibility of having their own validation set, but at the same time do not allow to hide fields which are not even mandatory.
@punchagan, we already talked at length about it and you said you'd give it more thought. Please comment, if you have some further thoughts on that.
Related to this incident: #213
The text was updated successfully, but these errors were encountered: