Another use case: a custom Live Data source backed by a remote service. The OpenProject integration (Live Data source projectmanagement) declares, for each property, only the operators that OpenProject supports for that field (e.g. ~ and Unable to render embedded object: File (~}} for the subject, {{=}} and {{) not found. for the id). Since the operators of the default configuration (liveDataConfiguration.json) are always merged in, the filter panel also offers "Starts with", "Equals", "Contains", "Empty", "<" and ">" on these properties, and when the user picks one the remote service rejects the query, so the Live Data only shows "Updating the entries failed for an unknown reason".
The only thing such a source can do is to translate each generic operator into the closest one supported by the remote service, or ignore it, which means the UI offers operators that don't do what their name says (e.g. "Equals" on the subject behaving as "Contains").
+1 for a way for a source (and for a property descriptor) to restrict the operators, e.g. the "activated": false flag proposed by Manuel, which keeps the current merge behaviour.
Vincent Massol on 06/Nov/26 17:13
Another use case: a custom Live Data source backed by a remote service. The OpenProject integration (Live Data source {{projectmanagement}}) declares, for each property, only the operators that OpenProject supports for that field (e.g. {{~}} and {{\!~}} for the subject, {{=}} and {{\!}} for the id). Since the operators of the default configuration ({{liveDataConfiguration.json}}) are always merged in, the filter panel also offers "Starts with", "Equals", "Contains", "Empty", "<" and ">" on these properties, and when the user picks one the remote service rejects the query, so the Live Data only shows "Updating the entries failed for an unknown reason".
The only thing such a source can do is to translate each generic operator into the closest one supported by the remote service, or ignore it, which means the UI offers operators that don't do what their name says (e.g. "Equals" on the subject behaving as "Contains").
+1 for a way for a source (and for a property descriptor) to restrict the operators, e.g. the {{"activated": false}} flag proposed by Manuel, which keeps the current merge behaviour.
Vincent Massol on 06/Nov/26 17:13
Another use case: a custom Live Data source backed by a remote service. The OpenProject integration (Live Data source {{projectmanagement}}) declares, for each property, only the operators that OpenProject supports for that field (e.g. {{\~}} and {{\!\~}} for the subject, {{=}} and {{\!}} for the id). Since the operators of the default configuration ({{liveDataConfiguration.json}}) are always merged in, the filter panel also offers "Starts with", "Equals", "Contains", "Empty", "<" and ">" on these properties, and when the user picks one the remote service rejects the query, so the Live Data only shows "Updating the entries failed for an unknown reason".
The only thing such a source can do is to translate each generic operator into the closest one supported by the remote service, or ignore it, which means the UI offers operators that don't do what their name says (e.g. "Equals" on the subject behaving as "Contains").
+1 for a way for a source (and for a property descriptor) to restrict the operators, e.g. the {{"activated": false}} flag proposed by Manuel, which keeps the current merge behaviour.
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
