Opened 16 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: | 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 , 16 years ago
Keywords: | verify added |
---|---|
Milestone: | → 0.11.1 |
comment:2 by , 16 years ago
Keywords: | verify removed |
---|---|
Owner: | changed from | to
comment:3 by , 16 years ago
Milestone: | 0.11.2 → 0.11.1 |
---|
When fixing this, also remember to test the issue of reopened comment:ticket:1467:14.
comment:4 by , 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
593 593 for field in self.fields: 594 594 if field['type'] == 'textarea': 595 595 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'] 596 600 field_data = {} 597 601 field_data.update(field) 598 602 del field_data['name']
Does other devs agree with this change?
comment:5 by , 16 years ago
Milestone: | 0.11.1 → 0.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 , 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 , 16 years ago
Keywords: | query restrict_owner added |
---|---|
Milestone: | 0.11-retriage → 0.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 587 587 588 588 fields = {} 589 589 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') 590 593 field_data = {} 591 594 field_data.update(field) 592 595 del field_data['name']
This would be a somewhat lower impact change as it keeps everything else as-is.
follow-up: 10 comment:9 by , 16 years ago
Status: | new → assigned |
---|
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.
comment:10 by , 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 , 16 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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.
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.