Vote #69012
完了Issue custom query: default query per instance, project and user
0%
説明
It would be nice to be able to create a default custom query, so when I get to issue list of a project, I don't need to select my preferable custom query from the list.
journals
+1 This would be great!
--------------------------------------------------------------------------------
+1 definitely, been wanting this for ages! Ideally each user would be able to determine their own custom query for each project, rather than it being a project-level setting.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
+1 Indeed would be nice for a user to set is default query for a given project. So a user could create a query to see only his tickets or the ticket related to a version he is currently working on. In fact he can already do all of this. Only thing missing is to automatically have that list query displayed when he clicks on "Issues".
--------------------------------------------------------------------------------
+1 very important
--------------------------------------------------------------------------------
+1
And, if the query is a public query, then you should have the option of specifying whether it's the default for everyone or just your own personal default.
--------------------------------------------------------------------------------
+1 Very important
--------------------------------------------------------------------------------
+1 for that feature that we should not forget.
--------------------------------------------------------------------------------
+1 Super important
--------------------------------------------------------------------------------
+1
Reducing just one click seems like such a waste of coding time, but clicking a couple of hundred times every week twice as much is such a waste of effort. This would be a huge usability improvement.
--------------------------------------------------------------------------------
+1 Very much important. One must click his favorite issus pages when new html page open. It takes a lot of time from many users by redoing that.
--------------------------------------------------------------------------------
+1 And if the query is public, it would be usefull to have an option to put the query default for every users.
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
+1 I'm going to do that myself
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
Yes this could be quite useful. I have some projects which needs a special filter or a special column display (due to some custom fields) to get displayed correct. If there would be a default view, for each user in each project or a default project with the new role wide filters, this would be great.
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
+1 Important everyone views important information on issues list without having to select custom query every time.
--------------------------------------------------------------------------------
+1
Each time we open the tasks list, every one of us has to rearrange the list before starting to use it. We have custom queries but you forget to select them. This feature would save a huge amount of time and bad language :)
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
+1
That would save me a lot of time.
--------------------------------------------------------------------------------
+1
I also hope strongly that this feature is implemented. So, i made the "redmine_default_custom_query":http://www.redmine.org/plugins/redmine-default-custom-query plugin as an alternative.
--------------------------------------------------------------------------------
@Hidaka Katsuya,
+1
--------------------------------------------------------------------------------
Hidaka Katsuya wrote:
> +1
> I also hope strongly that this feature is implemented. So, I made the "redmine_default_custom_query":http://www.redmine.org/plugins/redmine-default-custom-query plugin as an alternative.
Maybe you can send a patch file to the redmine developers so they can add it easily.
--------------------------------------------------------------------------------
Florian Kaiser wrote:
> Maybe you can send a patch file to the redmine developers so they can add it easily.
Yes, i'll try.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
+1
This would really make everything more readable and would make life easier for our everyday users.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
I made a patch. It integrates Katsuya Hidaka's plugin ("redmine_default_custom_query":http://www.redmine.org/plugins/redmine_default_custom_query) to Redmine.
I do appreciate Katsuya Hidaka's work. and I would be happy if I could see the feature in Redmine 3.3.0.
this patch is compatibled with latest trunk r15273. and It also includes the test code.
--------------------------------------------------------------------------------
I have arranged my patch ( attachment:default_custom_query_trunk_r15273.patch ) for berow:
* add 'default_query_id' to "Project(projects) "
* change position of the 'default-query drop-down', to 'Information Tab'
* remove permission & module "Manage default query"
* improve code a little bit, and add tests
* Compatible with latest trunk (r15303)
--------------------------------------------------------------------------------
attachment:default_custom_query_trunk_r15303.patch works fine and passed all test.
This is a great feature. Many users hope for this feature (this issue have got 24 "+1"s and the original plugin "redmine_default_custom_query":https://github.com/hidakatsuya/redmine_default_custom_query written by Katsuya HIDAKA have got 25 stars on GitHub).
It would be great if we could see this feature in the next release. Now I am setting target version to 3.3.0.
--------------------------------------------------------------------------------
Screenshots of the patch, contributed by Katsuya HIDAKA and Takenori TAKAKI.
!default-query-settings.png!
!default-query-list.png!
--------------------------------------------------------------------------------
+1 I'm creator of Default Custom Query plugin. I think that this patch (based on Default Custom Query plugin and written by Takenori Takaki) is one of the best way for providing customization of default issues for each project. I hope that this feature is merged!!
--------------------------------------------------------------------------------
As requested above, we should provide different level of default query: per project (as implemented in the patch) but also by user. We should also be able to provide default queries for the global issue list.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
+1, this would be wonderful.
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Let's try to keep this on the roadmap; setting target to unplanned.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
+1
The patch of #7360#note-36 which was not working according to version upgrade was fixed to work on trunk.
I would like the continuation of work to realize this feature.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
+1 !
Is there any reason this feature / patch got rejected? Would be really useful to have something like this... Maybe 4.1.0?!
--------------------------------------------------------------------------------
+1 !
--------------------------------------------------------------------------------
+1!
I hope that this feature will be release soon too. It's very annoying. It should be possible to define a global default filter and then save a dedicated filter per project.
--------------------------------------------------------------------------------
I would like to throw my +1 into the ring! This functionality would be super beneficial to have native to Redmine. Crossing my fingers for 4.1.0 (or sooner!)...
--------------------------------------------------------------------------------
+1
Is this patch workable on 4.0.4 ? Because "redmine_default_custom_query" is conflict with DMSF. So I am seeking another solution with same function.
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
I really would like to see this integrated in redmine by default. It was more or less accepted in https://www.redmine.org/issues/7360#note-40 - any idea why its now on unplanned backlog?
--------------------------------------------------------------------------------
Marcel Müller wrote:
> I really would like to see this integrated in redmine by default. It was more or less accepted in https://www.redmine.org/issues/7360#note-40 - any idea why its now on unplanned backlog?
The current patch was rejected by Jean-Philippe Lang in #7360#note-40 because of the lack of per-user default query and a default query for the cross-project issues list.
To push this issue forward, someone needs to implement at least those features.
--------------------------------------------------------------------------------
Hi,
You can find an updated version of patch for this feature.
This patch work with last commit r19977 on trunk branch.
this patch provide also different level of default query (as requested on #7360#note-40):
* per project (as implemented in the original patch)
* per user
* and in the global redmine settings for the global issue list
thank you for your reviews on this patch ;)
--------------------------------------------------------------------------------
Hello,
Does anyone have time to review my patch ?
thanks ;)
--------------------------------------------------------------------------------
+1, absolutely! Seeing all issues ordered by issue # per default is definitively suboptimal behaviour in my eyes.
--------------------------------------------------------------------------------
@Oliver Chabert: Thanks for your effort. Can you confirm that the patch works with Redmine 4.1.2?
@Mike Kokhanov: Please can you review this patch, comment, or forward this to someone else for reviewing?
--------------------------------------------------------------------------------
We're planning to introduce this feature in "Planio":https://plan.io/redmine-hosting , so I took the liberty to look over Olivier's patch (thank you for that!) and, among other things, rebased it on current master.
Further, I added some tests and German translations, fixed any rubocop warnings, implemented copying of the default query assignment when copying a project including queries, and changed the naming of preferences / fields to be consistently @default_issue_query@.
--------------------------------------------------------------------------------
@Jens Krämer: Do you know anything I can do to get the patch into the main code?
--------------------------------------------------------------------------------
Setting the target version to 5.0.0.
--------------------------------------------------------------------------------
The patch looks good to me, nice work!
Only one thing, is not better to show the _Default query_ field inside _Issues list defaults_ section in admin? The settings are quite related:
Current proposal:
!{width: 30%; border: 1px solid grey;}a.png!
My proposal:
!{width: 30%; border: 1px solid grey;}b.png!
--------------------------------------------------------------------------------
Marius BALTEANU wrote:
> Only one thing, is not better to show the _Default query_ field inside _Issues list defaults_ section in admin? The settings are quite related:
+1
The setting "Default query" is exactly "Issue list defaults"!
I have updated the patch as such and changed the date of the migration file to the current date.
Although an earlier version of the patch contributed by Katsuya HIDAKA and Takenori TAKAKI was rejected by JPL 5 years ago (#7360#note-40), I got approval from Jean-Philippe Lang to commit the latest patch the day before yesterday. I would like to commit the patch within the next few days.
--------------------------------------------------------------------------------
Committed the patch. Thank you to all those who contributed to this great feature, and special thanks to Katsuya HIDAKA, the author of "Redmine Default Custom Query":https://github.com/hidakatsuya/redmine_default_custom_query.
Now you can set the default issue query per app/project/user. The project-level default query always overrides the app-level one, and the user-level one always overrides the project-level and app-level ones.
You can configure default queries in the following places:
* App-level: Administration > Issue tracking > Default Query
* Project-level: Settings (project) > Issue tracking > Default issue query
* User-level: My account > Default issue query
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
The current code executes as many SQL statements as the number of queries displayed in the sidebar. It may cause a performance issue when many custom queries are displayed in the sidebar.
The attached patch fixes the problem.
*Before:*
<pre>
IssueQuery Load (0.1ms) SELECT "queries".* FROM "queries" WHERE "queries"."type" = ? AND "queries"."id" IS NULL LIMIT ? [["type", "IssueQuery"], ["LIMIT", 1]]
CACHE IssueQuery Load (0.0ms) SELECT "queries".* FROM "queries" WHERE "queries"."type" = ? AND "queries"."id" = ? LIMIT ? [["type", "IssueQuery"], ["id", 4], ["LIMIT", 1]]
CACHE IssueQuery Load (0.0ms) SELECT "queries".* FROM "queries" WHERE "queries"."type" = ? AND "queries"."id" IS NULL LIMIT ? [["type", "IssueQuery"], ["LIMIT", 1]]
CACHE IssueQuery Load (0.0ms) SELECT "queries".* FROM "queries" WHERE "queries"."type" = ? AND "queries"."id" IS NULL LIMIT ? [["type", "IssueQuery"], ["LIMIT", 1]]
CACHE IssueQuery Load (0.0ms) SELECT "queries".* FROM "queries" WHERE "queries"."type" = ? AND "queries"."id" IS NULL LIMIT ? [["type", "IssueQuery"], ["LIMIT", 1]]
CACHE IssueQuery Load (0.0ms) SELECT "queries".* FROM "queries" WHERE "queries"."type" = ? AND "queries"."id" IS NULL LIMIT ? [["type", "IssueQuery"], ["LIMIT", 1]]
CACHE IssueQuery Load (0.0ms) SELECT "queries".* FROM "queries" WHERE "queries"."type" = ? AND "queries"."id" IS NULL LIMIT ? [["type", "IssueQuery"], ["LIMIT", 1]]
CACHE IssueQuery Load (0.0ms) SELECT "queries".* FROM "queries" WHERE "queries"."type" = ? AND "queries"."id" IS NULL LIMIT ? [["type", "IssueQuery"], ["LIMIT", 1]]
CACHE IssueQuery Load (0.0ms) SELECT "queries".* FROM "queries" WHERE "queries"."type" = ? AND "queries"."id" IS NULL LIMIT ? [["type", "IssueQuery"], ["LIMIT", 1]]
CACHE IssueQuery Load (0.0ms) SELECT "queries".* FROM "queries" WHERE "queries"."type" = ? AND "queries"."id" IS NULL LIMIT ? [["type", "IssueQuery"], ["LIMIT", 1]]
CACHE IssueQuery Load (0.0ms) SELECT "queries".* FROM "queries" WHERE "queries"."type" = ? AND "queries"."id" IS NULL LIMIT ? [["type", "IssueQuery"], ["LIMIT", 1]]
CACHE IssueQuery Load (0.0ms) SELECT "queries".* FROM "queries" WHERE "queries"."type" = ? AND "queries"."id" IS NULL LIMIT ? [["type", "IssueQuery"], ["LIMIT", 1]]
CACHE IssueQuery Load (0.0ms) SELECT "queries".* FROM "queries" WHERE "queries"."type" = ? AND "queries"."id" IS NULL LIMIT ? [["type", "IssueQuery"], ["LIMIT", 1]]
CACHE IssueQuery Load (0.0ms) SELECT "queries".* FROM "queries" WHERE "queries"."type" = ? AND "queries"."id" IS NULL LIMIT ? [["type", "IssueQuery"], ["LIMIT", 1]]
CACHE IssueQuery Load (0.0ms) SELECT "queries".* FROM "queries" WHERE "queries"."type" = ? AND "queries"."id" IS NULL LIMIT ? [["type", "IssueQuery"], ["LIMIT", 1]]
CACHE IssueQuery Load (0.0ms) SELECT "queries".* FROM "queries" WHERE "queries"."type" = ? AND "queries"."id" IS NULL LIMIT ? [["type", "IssueQuery"], ["LIMIT", 1]]
CACHE IssueQuery Load (0.0ms) SELECT "queries".* FROM "queries" WHERE "queries"."type" = ? AND "queries"."id" IS NULL LIMIT ? [["type", "IssueQuery"], ["LIMIT", 1]]
CACHE IssueQuery Load (0.0ms) SELECT "queries".* FROM "queries" WHERE "queries"."type" = ? AND "queries"."id" IS NULL LIMIT ? [["type", "IssueQuery"], ["LIMIT", 1]]
Rendered issues/_sidebar.html.erb (Duration: 33.7ms | Allocations: 5906)
</pre>
*After:*
<pre>
IssueQuery Load (0.1ms) SELECT "queries".* FROM "queries" WHERE "queries"."type" = ? AND "queries"."id" IS NULL LIMIT ? [["type", "IssueQuery"], ["LIMIT", 1]]
CACHE IssueQuery Load (0.0ms) SELECT "queries".* FROM "queries" WHERE "queries"."type" = ? AND "queries"."id" = ? LIMIT ? [["type", "IssueQuery"], ["id", 4], ["LIMIT", 1]]
CACHE IssueQuery Load (0.0ms) SELECT "queries".* FROM "queries" WHERE "queries"."type" = ? AND "queries"."id" IS NULL LIMIT ? [["type", "IssueQuery"], ["LIMIT", 1]]
Rendered issues/_sidebar.html.erb (Duration: 18.3ms | Allocations: 3276)
</pre>
--------------------------------------------------------------------------------
Go MAEDA wrote:
> The current code executes as many SQL statements as the number of queries displayed in the sidebar. It may cause a performance issue when many custom queries are displayed in the sidebar.
>
> The attached patch fixes the problem.
Attaching a simpler and more efficient version of the patch.
--------------------------------------------------------------------------------
Go MAEDA wrote:
> Attaching a simpler and more efficient version of the patch.
FWIW, the following assignment:
<pre><code class="ruby">
default_query =
default_query_by_class[query.class] ||
default_query_by_class[query.class] = query.class.default(project: @project)
</code></pre>
can (possibly) be shortened to:
<pre><code class="ruby">
default_query =
default_query_by_class[query.class] ||= query.class.default(project: @project)
</code></pre>
Ref. on "StackOverflow":https://stackoverflow.com/questions/995593/what-does-or-equals-mean-in-ruby/14697343.
--------------------------------------------------------------------------------
Committed patch #7360#note-88 with the change suggested by Mischa The Evil in #7360#note-89.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Before committing #35795, I would like to change the local @setting_default_issue_query@ to @setting_default_query@ in order to not add a new key (@setting_default_project_query@) to locales with the same translation ("Default query").
Go Maeda, do you see any problem?
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Marius BALTEANU wrote:
> Before committing #35795, I would like to change the local @setting_default_issue_query@ to @setting_default_query@ in order to not add a new key (@setting_default_project_query@) to locales with the same translation ("Default query").
>
> Go Maeda, do you see any problem?
I think there isn't any problem. And all existing translations for the key don't include a word corresponding to 'issue', so it is safe to simply change the name of the key.
<pre>
config/locales/bg.yml: setting_default_issue_query: Заявка по подразбиране
config/locales/de.yml: setting_default_issue_query: Standardabfrage
config/locales/fr.yml: setting_default_issue_query: Rapport par défaut
config/locales/gl.yml: setting_default_issue_query: Consulta por defecto
config/locales/ja.yml: setting_default_issue_query: デフォルトのクエリ
config/locales/zh-TW.yml: setting_default_issue_query: 預設查詢
</pre>
--------------------------------------------------------------------------------
Go MAEDA wrote:
> I think there isn't any problem. And all existing translations for the key don't include a word corresponding to 'issue', so it is safe to simply change the name of the key.
>
Thanks, change committed.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
I'm reopening this in order to validate the fix for the issue reported in #36389.
Jens Krämer, can you take a look, please?
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
I've committed the fix.
--------------------------------------------------------------------------------
related_issues
relates,Closed,8479,Global default query
relates,Closed,5515,user select default issue query
relates,New,4015,Make app settings overridable at project level
relates,New,13508,About default filter for assignee
relates,Closed,7659,Add the possibility to sort issues by last_update date, by default
relates,Closed,3967,Ability to define default columns to display based on project
relates,Closed,14753,Remember issue filter for each project
relates,Closed,35795,Settings for global and user default custom ProjectQuery
relates,Closed,36389,Filter parameters of Query string do not work when default query is enabled
relates,Closed,36503,Reduce extra queries in IssueQuery.default
duplicates,Closed,7999,Issue Custom Query: Default Query
duplicates,Closed,12689,Default query for every Project
duplicates,Closed,7244,Default query per project
duplicates,Closed,16102,Default Filters for queries in a project
duplicates,Closed,2829,Ability to set default search filter for Issues
duplicates,Closed,7993,Select Default Report (or Custom Report quick links)
duplicates,Closed,9279,How to Apply custom queries for issues as default view for this project
duplicates,Closed,22156,Is there a way to set the filter status to be “Any” by default?
duplicates,Closed,16249,Configure columns per project
duplicates,Closed,15566,Setup a default issue report for each project
duplicates,Closed,27128,Ability to choose default sort by column for all projects
duplicates,Closed,36198,Set standard columns in the ticket listing options based on projects