Feature #9445

Add Issue custom fields of User-format to the cross-project issuelist filters

Added by Lubor Nosek over 5 years ago. Updated 6 months ago.

Status:NewStart date:2011-10-21
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Custom fields
Target version:Candidate for next minor release
Resolution:

Description

We have added custom field into Issues named Supervisor which is a User format and checked Use as filter and For all projects.

When we display all issues (/issues) this custom field cannot be used as a filter.

I think the reason behind this is that the custom field maps on project users and these users are different across different projects.

Nevertheless I think that current behaviour is not correct and this custom field should be enabled as a filter in all issues display.

We're using Redmine 1.2.1.stable.6294 (MySQL)

ScreenHunter_13 Oct. 23 08.54.jpg - Screen shot of custom query with custom field (135 KB) Branden Strickland, 2013-10-23 14:56

0001-Add-Issue-custom-fields-of-User-format-to-the-cross-.patch Magnifier - Patch for 2.6-stable branch (2.11 KB) Anders Thomsen, 2015-08-07 16:47

issue_9445_user_custom_field_global_queries.diff Magnifier - patch against trunk (as of 2015/12/02) (1.71 KB) Jens Krämer, 2015-12-02 05:17


Related issues

Related to Redmine - Defect #10176: Custom fields of type "User" can't be ordered New
Related to Redmine - Defect #18940: Filter by custom user field didn´t work New
Duplicated by Redmine - Defect #9689: Cannot use a custom field with User format as filter Closed 2011-11-29
Duplicated by Redmine - Defect #9924: Custom field not filter option at global scope Closed
Duplicated by Redmine - Defect #9920: Custom fields of type "User" can't be ordered and used in... Closed

History

#1 Updated by Lubor Nosek over 5 years ago

Please correct spelling mistake in Subject: filed -> field

#2 Updated by Mischa The Evil over 5 years ago

  • Tracker changed from Defect to Feature
  • Subject changed from Issue custom filed with User type cannot be filtered globally to Add Issue custom fields of User-format to the cross-project issuelist filters

Corrected.

#3 Updated by pasquale [:dedalus] over 5 years ago

+1

#4 Updated by pasquale [:dedalus] over 5 years ago

I don't agree that this is a feature and not a bug because assignee-to is a User format type

#5 Updated by Joe Cullin about 5 years ago

+1

#6 Updated by Fernando Hartmann almost 5 years ago

+1

#7 Updated by Vincent Desmarets over 4 years ago

+1
this is a really important fix for my projects. without this we cannot have an overall view on all projects

#8 Updated by Vincent Desmarets over 4 years ago

  • Assignee set to Mischa The Evil

#9 Updated by James Silver about 4 years ago

+1!

Very important for those of us using a custom user field for things like "Supervisor" fields.

Thanks!

#10 Updated by Koen Boone about 4 years ago

+100!

I have a custom user field for issues that is available for ALL projects, but it's not available in the filter for issues for all projects, only in lists per project.
Maybe this is because it's not used yet in all issues, but I think it's also related to this thread.

#11 Updated by Mischa The Evil about 4 years ago

  • Assignee deleted (Mischa The Evil)

Vincent Desmarets wrote:

  • Assignee set to Mischa The Evil

Please don't randomly assign issues.

#12 Updated by Branden Strickland over 3 years ago

All,

I've mucked around a bit and gotten this to work.

This is with the EXPRESS WARNING that it may break other things - and that I've hacked mine a bit on the dirty side and need to clean it up.

In models/querys.rb
at

def add_custom_fields_filters(custom_fields, assoc=nil)

Down where it says

When "user", "version" 
next unless project
values = field.possible_values_options(project)

I've just commented out "next unless project" which as I understand is basically requiring a project to be associated with that custom field type. I want global - so I"m willing to risk a bit of wierdness to get it since it's a deal-breaker not to have it.

This was done with the help of rchady in IRC - and he's warned me this could blow up as well - but I'm willing to risk it and test on my testing env. So far it's exactly as intended.

This should also be broken up between user vs version to make it cleaner.

I may regret this later but as of now - I'm getting my global "view all tickets" custom query to take in account a custom user field and I love it - The boss is pretty happy too! (until it breaks!)

#13 Updated by Mischa The Evil over 3 years ago

Branden Strickland wrote:

I've mucked around a bit and gotten this to work.
[...]
In models/querys.rb at def add_custom_fields_filters(custom_fields, assoc=nil), down where it says:

when "user", "version" 
  next unless project
  values = field.possible_values_options(project)
I've just commented out "next unless project"
[...]

I don't see how this could work. Do you really see (other) project members shown as possible values for the filter on the cross-project issue list? AFAICS the only possible value that could be shown in this filter after a change like this is "<< me >>".

#14 Updated by Branden Strickland over 3 years ago

I'm happy to provide further details.

OH! I see what you're saying Mischa! Yeah - It only gives the option for <<me>> But in our case - this is what we needed since we're looking to display tickets that are either owned by the person, or if they're a direct supporting owner.

I've not needed to - nor have I attempted to make that searchable for other peoples names. Although I would suspect possibly doing something with user.current.logged and mucking with the field == {'custom value db field'} or something that would allow the same functionality of selecting possible users for watchers or assigned_to_id but I'm just shooting that off the hip.

#15 Updated by Branden Strickland over 3 years ago

Just an update - I finally had the question posed to me "Hey - can we have custom filters with options other than "<<me>>"? Us managers should be able to see for any person.

Well as Mischa The Evil mentioned earlier, it's not that easy (duh). I hacked around for about 30 minutes until I decided I should stick to PHP... Also - I started looking at this outside the box.

If need be - You can do what I did to make up for this (not pretty - buckle in!)

I went into the database - where I'm comfortable (much more so than in Ruby) and I saw that the Queries Table lists all of the public and private custom queries. I then referenced the User Table and found if I do something like so

INSERT INTO `redmine`.`queries` (`name`, `filters`, `user_id`, `is_public`, `column_names`, `sort_criteria`, `group_by`, `type`) VALUES ('Example', '---\nstatus_id:\n  :operator: o\n  :values:\n  - \'\'\nuseor:\n  :operator: =\n  :values:\n  - \'Yes\'\nassigned_to_id:\n  :operator: =\n  :values:\n  - {USERID}\ncf_1:\n  :operator: =\n  :values:\n  - {USERID}\n', 3, 1, '---\n- :project\n- :tracker\n- :subject\n- :status\n- :priority\n- :parent\n- :assigned_to\n- :cf_1\n- :done_ratio\n- :due_date\n- :estimated_hours\n- :spent_hours\n', '---\n- - due_date\n  - asc\n', '', 'IssueQuery');

Where cf_1 is the id of the custom field. and {USERID} is the.. well.. Userid from the users table.

To simplify - if you were to edit just the filter column in something like... HeidiSQL it would like like so:

---
status_id:
  :operator: o
  :values:
  - ''
useor:
  :operator: =
  :values:
  - 'Yes'
assigned_to_id:
  :operator: =
  :values:
  - '12'
cf_1:
  :operator: =
  :values:
  - '12'

That I could hack out custom queries for my users. This is NOT for someone who has to do super custom for > 10 users, but in my case I just need to create 10 or so public queries to show all tickets accross all projects that were either assigned to OR marked as "Other Assignee" (a custom field) on the ticket.

A note! This does require the "OR" filter plugin that is available in the plugins section.

#16 Updated by Ty You almost 3 years ago

This is a whammy for us, too. I'm on 2.3.2.stable - does anyone know if this has been addressed in subsequent versions? I can't hack core, too much pressure ;-)

#18 Updated by Anders Thomsen over 2 years ago

+1

#19 Updated by Anders Thomsen over 2 years ago

Managed to get this sort of working.

It fetches all active users from the entire DB!!!

One bug though: when browsing to an issue from the ROOT/issues page, it loads all users but does not add it anywhere to the rendered page. This is even though I test if there is a project with project.nil?. When browsing to an issue from the ROOT/project/issues page it skips loading all users, like it should.

In app/models/query.rb

  def add_custom_field_filter(field, assoc=nil)
    options = field.format.query_filter_options(field, self)
    if field.format.target_class && field.format.target_class <= User
# BEGIN PATCH
       # If showing all issues in all projects, select all active users
      if options[:values].is_a?(Array) && project.nil? &&         
        options[:values] = User.active.sorted.collect {|u| [u.to_s, u.id.to_s]} 
      end
# END PATCH
      if options[:values].is_a?(Array) && User.current.logged?
        options[:values].unshift ["<< #{l(:label_me)} >>", "me"]        
      end      
    end
...

#20 Updated by Anders Thomsen over 2 years ago

Even better solution. It now shows all members of projects and uses the same list as "watchers":

In app/models/query.rb

 # Adds a filter for the given custom field
  def add_custom_field_filter(field, assoc=nil, valid_users=nil)
    options = field.format.query_filter_options(field, self)
    if field.format.target_class && field.format.target_class <= User
      if options[:values].is_a?(Array) && User.current.logged?
        options[:values].unshift ["<< #{l(:label_me)} >>", "me"]
      end
      if options[:values].is_a?(Array) && project.nil? && !valid_users.nil?        
        options[:values] += valid_users.collect {|u| [u.name, u.id.to_s]} 
      end      
    end
...

  def add_custom_fields_filters(scope, assoc=nil, valid_users=nil)
    scope.visible.where(:is_filter => true).sorted.each do |field|
      add_custom_field_filter(field, assoc, valid_users)
    end
  end

In app/models/issue_query.rb in the method initialize_available_filters add users to the parameter list like so:

    add_custom_fields_filters(issue_custom_fields, nil, users)

Tested on version 2.5.2

#21 Updated by Anton Statutov about 2 years ago

How about making patch for this?

#22 Updated by Mischa The Evil about 2 years ago

  • Related to Defect #18940: Filter by custom user field didn´t work added

#24 Updated by Anders Thomsen over 1 year ago

My changes as a patch for 2.6.6. Not tested with 3.x

#25 Updated by Jens Krämer over 1 year ago

I can confirm that this change also works on trunk, just the line numbers in the original patch are a bit off.

#26 Updated by Jan from Planio www.plan.io over 1 year ago

  • Target version set to Candidate for next minor release

#27 Updated by Anders Thomsen over 1 year ago

I'm using the patch against 3.1 with no problems. So it seems to work.

What's the next step? Should I submit it as a patch or just leave it here and get the devs' attention somehow?

#28 Updated by Toshi MARUYAMA about 1 year ago

Anders Thomsen wrote:

I'm using the patch against 3.1 with no problems. So it seems to work.

What's the next step? Should I submit it as a patch or just leave it here and get the devs' attention somehow?

Please add tests.

#29 Updated by Chandranshu . 6 months ago

The patch is good as a workaround hack but I don't think we should merge it to the trunk yet. I have configured my custom field to only allow users of a particular role but using this patch, I can see all the users listed in the filter drop-down. I'll try to improve this patch to take that into account.

Also available in: Atom PDF