- 19 Oct, 2016 4 commits
-
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
- 30 Sep, 2016 1 commit
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 20 Sep, 2016 1 commit
-
-
barthc authored
-
- 30 Aug, 2016 1 commit
-
-
http://jneen.net/ authored
-
- 01 Aug, 2016 1 commit
-
-
zs authored
Provide more sensible default sort order for issues and merge requests based on the following table: | type | state | default sort order | |----------------|--------|--------------------| | issues | open | last created | | issues | closed | last updated | | issues | all | last created | | merge requests | open | last created | | merge requests | merged | last updated | | merge requests | closed | last updated | | merge requests | all | last created |
-
- 06 Jun, 2016 2 commits
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Thijs Wouters authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 03 Jun, 2016 2 commits
-
-
James Lopez authored
This reverts commit 3e991230.
-
James Lopez authored
# Conflicts: # app/models/project.rb
-
- 31 May, 2016 1 commit
-
-
Felipe Artur authored
-
- 24 May, 2016 2 commits
-
-
Felipe Artur authored
-
Felipe Artur authored
-
- 16 May, 2016 1 commit
-
-
Sean McGivern authored
Before: we took the next milestone due across all projects in the search and found issues whose milestone title matched that one. Problems: 1. The milestone could be closed. 2. Different projects have milestones with different schedules. 3. Different projects have milestones with different titles. 4. Different projects can have milestones with different schedules, but the _same_ title. That means we could show issues from a past milestone, or one that's far in the future. After: gather the ID of the next milestone on each project we're looking at, and find issues with those milestone IDs. Problems: 1. For a lot of projects, this can return a lot of IDs. 2. The SQL query has to be different between Postgres and MySQL, because MySQL is much more lenient with HAVING: as well as the columns appearing in GROUP BY or in aggregate clauses, MySQL allows them to appear in the SELECT list (un-aggregated).
-
- 21 Apr, 2016 1 commit
-
-
Rémy Coutable authored
This is not needed anymore after !3815. Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 20 Apr, 2016 7 commits
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Mehmet Beydogan authored
Fix typos on sorting dropdown related to due date Remove constant array and add Structs on Issue to keep due date data to fill options
-
Mehmet Beydogan authored
Add due_date text field to sidebar issue#show Add ability sorting issues by due date ASC and DESC Add ability to filtering issues by No Due Date, Any Due Date, Due to tomorrow, Due in this week options Add handling issue due_date field for MergeRequest Update CHANGELOG Fix ambigous match for issues#show sidebar Fix SCREAMING_SNAKE_CASE offenses for due date contants Add specs for due date sorting and filtering on issues
-
Phil Hughes authored
Fixed issue with no label not working correctly
-
James Lopez authored
-
- 19 Apr, 2016 1 commit
-
-
James Lopez authored
-
- 13 Apr, 2016 1 commit
-
-
Yorick Peterse authored
This ensures that IssuableFinder returns a collection of unique issues, even when filtering issues using multiple labels.
-
- 29 Mar, 2016 2 commits
-
-
Phil Hughes authored
The frontend will then always use the name as the ID - like previous
-
Phil Hughes authored
Added back upcoming to milestone filter Fixed bug that would cause the currently selected value to disappear on filters Fixed bug that throw an error when filtering by upcoming when there is only a milestone in the past
-
- 21 Mar, 2016 1 commit
-
-
Douwe Maan authored
-
- 20 Mar, 2016 2 commits
-
-
Douwe Maan authored
-
Douwe Maan authored
-
- 13 Mar, 2016 1 commit
-
-
tiagonbotelho authored
-
- 12 Mar, 2016 3 commits
-
-
tiagonbotelho authored
-
tiagonbotelho authored
-
tiagonbotelho authored
-
- 07 Mar, 2016 1 commit
-
-
Rubén Dávila authored
-
- 19 Feb, 2016 2 commits
- 18 Jan, 2016 1 commit
-
-
Yorick Peterse authored
When using IssuableFinder with a Group we can greatly reduce the amount of projects operated on (due to not including all public/internal projects) by simply passing it down to the ProjectsFinder class. This reduces the timings of the involved queries from roughly 300 ms to roughly 20 ms. Fixes gitlab-org/gitlab-ce#4071, gitlab-org/gitlab-ce#3707
-
- 07 Jan, 2016 1 commit
-
-
Yorick Peterse authored
When grabbing the projects to filter issues by we don't care about the order they're returned in. By removing the ORDER BY the resulting query can be quite a bit faster.
-