Edgewall Software
Modify

Opened 17 years ago

Closed 16 years ago

#7258 closed defect (fixed)

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

Reported by: Kamil Kisiel <kamil@…> Owned by: osimons
Priority: normal Milestone: 0.11.3
Component: report system Version: 0.11rc1
Severity: normal Keywords: query restrict_owner
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:

Description

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.

Attachments (0)

Change History (11)

comment:1 by Christian Boos, 17 years ago

Keywords: verify added
Milestone: 0.11.1

comment:2 by osimons, 16 years ago

Keywords: verify removed
Owner: changed from Matthew Good to 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.

comment:3 by osimons, 16 years ago

Milestone: 0.11.20.11.1

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

comment:4 by osimons, 16 years ago

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

     
    593593        for field in self.fields:
    594594            if field['type'] == 'textarea':
    595595                continue
     596            if field['name'] == 'owner' and field['type'] == 'select':
     597                # restrict_owner = true => make it a regular text field instead
     598                field['type'] = 'text'
     599                del field['options']
    596600            field_data = {}
    597601            field_data.update(field)
    598602            del field_data['name']

Does other devs agree with this change?

comment:5 by osimons, 16 years ago

Milestone: 0.11.10.11.2

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?

comment:6 by Remy Blank, 16 years ago

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.

comment:7 by osimons, 16 years ago

Keywords: query restrict_owner added
Milestone: 0.11-retriage0.11.3

#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

    a b  
    587587
    588588        fields = {}
    589589        for field in self.fields:
     590            if field['name'] == 'owner' and field['type'] == 'select':
     591                # Make $USER work when restrict_owner = true
     592                field['options'].insert(0, '$USER')
    590593            field_data = {}
    591594            field_data.update(field)
    592595            del field_data['name']

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

comment:8 by Remy Blank, 16 years ago

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

comment:9 by osimons, 16 years ago

Status: newassigned

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.

in reply to:  9 comment:10 by Christian Boos, 16 years ago

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.

comment:11 by osimons, 16 years ago

Resolution: fixed
Status: assignedclosed

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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain osimons.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from osimons to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.