Can't set owner to $USER in a query when restrict_owner is on

[Kamil Kisiel <kamil@…>]

Using the $USER variable normally allows you to specify the currently logged in user in a query, but there doesn't appear to be any way to achieve this when the restrict_owner option is set.

[osimons]

The issue is correctly stated.

Seeing 'reporter' with flexible options like 'is', 'is not', 'contains' and so on makes me wish for the same for 'owner' even with restrict_owner enabled. For reporting purposes that makes a lot of sense.

And, there is also an e-mail obfuscation issue involved: anyone with just TICKET_VIEW permission will get it obfuscated when viewing a specific ticket (properties are not available with just view), but in Custom Query it shows up as a filter unmodified.

+1 on making 'owner' like 'reporter' regardless of restrict_owner setting.

[osimons]

When fixing this, also remember to test the issue of reopened comment:ticket:1467:14.

[osimons]

Here is a patch to fix make the field 'owner' field always behave like a text field regardless of setting:

• more flexible querying using also contains, startswith, endswith and so on.
• supports $USER.
• e-mail obfuscation is no longer an issue if username is an email address and user only has TICKET_VIEW permissions.

trac/ticket/query.py

@@ -593 +593 @@
         for field in self.fields:
             if field['type'] == 'textarea':
                 continue
+            if field['name'] == 'owner' and field['type'] == 'select':
+                # restrict_owner = true => make it a regular text field instead
+                field['type'] = 'text'
+                del field['options']
             field_data = {}
             field_data.update(field)
             del field_data['name']

Does other devs agree with this change?

[osimons]

Remember seeing some other tickets and discussions that want similar treatment for versions, milestones, components and all similar select fields ('all versions starting with 0.10…'), and perhaps the right way to go about this is an option in the trac.ini [query] section that turns a switch to convert all select fields to regular text fields?

[rblank]

Another option would be to artificially add a $USER value in the query select box for the owner. Still, having "contains", "startswith" and other modes is useful, so I tend to prefer comment:4.

[osimons]

#7962 closed as duplicate.

It notes the behavior that if you hit the query with a owner=$USER arg the query works, but any subsequent updates will drop the $USER value as it cannot be selected in the dropdown and resubmitted.

Anyway, the solution in comment:6 would also work well. Tiny patch to inject $USER into the head of the dropdown:

trac/ticket/query.py

@@ -587 +587 @@
 
         fields = {}
         for field in self.fields:
+            if field['name'] == 'owner' and field['type'] == 'select':
+                # Make $USER work when restrict_owner = true
+                field['options'].insert(0, '$USER')
             field_data = {}
             field_data.update(field)
             del field_data['name']

This would be a somewhat lower impact change as it keeps everything else as-is.

[rblank]

A small preference for the first solution from my side (text field).

[osimons]

Finally found some tickets related to this issue and discussion: #5979, #5526

How about this plan - implementing both alternatives:

• We inject the $USER into the query users dropdown and solve this issue with minimum impact and let people continue to use select-type field.
• We make a [query] convert_to_text_fields = setting (or suggestion for better name) to list fields of choice to convert to text fields on a project-by-project basis. Some want it for users, some need it for selecting ranges of milestones, or that use it for a pseudo-components hierarchy or some custom field project-specific behaviour.

Neither will change behavior for 0.11, so unless someone objects, I'd like to commit to stable.

[cboos]

Replying to osimons:

Finally found some tickets related to this issue and discussion: #5979, #5526

How about this plan - implementing both alternatives:

• We inject the $USER into the query users dropdown and solve this issue with minimum impact and let people continue to use select-type field.

Ok.

• We make a [query] convert_to_text_fields = setting (or suggestion for better name) to list fields of choice to convert to text fields on a project-by-project basis. Some want it for users, some need it for selecting ranges of milestones, or that use it for a pseudo-components hierarchy or some custom field project-specific behaviour.

The problem I see with this approach is that only a Trac admin will be able to make this change and then it will apply globally, for everyone. I think we should rather think about a way that would allow advanced users to get this feature when they need to have it.

[osimons]

Committed the simple injection of $USER into select options in [7796:7797], and I'll make notes on #5979 and #5526 about the on-demand change of field type as an option to solving these tickets.