@Sfaci does this fit with your attribute selection / risk level hypothesis?

Good catch! I think it does. Thanks for point it out

Thanks to Andrew I have found we also have T385180: Implement agent.ua_string as contextual attribute. As far as I understand, that one seems to be what we want to implement here. Both tasks aim to allow users to decide, at the instrument level, when UA data will be collected and that one seems to propose an approach that seems doable. Regarding ACs of this ticket:

This will need input from Design

• We wouldn't need input from Design because we could use what we have already for the existing contextual attributes. UA data would be just a field that users can decide to collect or not

We will need to think about what happens if the user selects a base stream that has user agent collection disabled but the instrument owner wants to enable it

• According to T385180: Implement agent.ua_string as contextual attribute it seems that decoupling UA collection from the stream config: When we start managing contextual attributes via xLab rather than stream configs, it will be easy to turn UA collection on/off, without it being strongly coupled to the stream config

And that implementation would make easier to include UA data, as a contextual attribute, to the validation rules (T401390: xLab: New validation rules for selected contextual attributes and risk level when registering/modifying an instrument) we want to implement to provide some guidance to the users regarding the data they are going to collect and the corresponding risk level.

What do you think about merging both tickets and work on the contextual attribute as a way to implement it? Am I missing something?

In T397467#11083357, @Sfaci wrote:

What do you think about merging both tickets and work on the contextual attribute as a way to implement it? Am I missing something?

YES!

Great catch @Sfaci - merge away!