An error occurred fetching the project authors.
- 20 Sep, 2017 1 commit
-
-
Grzegorz Bizon authored
-
- 29 Aug, 2017 2 commits
-
-
Maxim Rydkin authored
-
Maxim Rydkin authored
-
- 07 Aug, 2017 1 commit
-
-
Sean McGivern authored
Group milestones can only be referred to by name, not IID. They also do not support cross-project references.
-
- 07 Jul, 2017 1 commit
-
-
Felipe Artur authored
-
- 06 Jul, 2017 1 commit
-
-
Yorick Peterse authored
This is allowed for existing instances so we don't end up 76 offenses right away, but for new code one should _only_ use this if they _have_ to remove non database data. Even then it's usually better to do this in a service class as this gives you more control over how to remove the data (e.g. in bulk).
-
- 21 Jun, 2017 1 commit
-
-
Grzegorz Bizon authored
-
- 16 Jun, 2017 3 commits
-
-
Felipe Artur authored
-
Felipe Artur authored
-
Felipe Artur authored
-
- 29 May, 2017 1 commit
-
-
Valery Sizov authored
-
- 04 May, 2017 1 commit
-
-
Valery Sizov authored
-
- 07 Apr, 2017 1 commit
-
-
Jacopo authored
Removed `Milestone#is_empty?` because is not used anymore in the codebase
-
- 02 Apr, 2017 1 commit
-
-
mhasbini authored
-
- 24 Mar, 2017 1 commit
-
-
George Andrinopoulos authored
-
- 15 Mar, 2017 1 commit
-
-
Sean McGivern authored
-
- 23 Feb, 2017 2 commits
-
-
Douwe Maan authored
This reverts commit cb10b725c8929b8b4460f89c9d96c773af39ba6b.
-
Douwe Maan authored
-
- 06 Jan, 2017 1 commit
-
-
Adam Niedzielski authored
-
- 03 Jan, 2017 1 commit
-
-
James Lopez authored
Also added relevant specs and refactored to_references in a bunch of places to be more consistent.
-
- 20 Dec, 2016 1 commit
-
-
James Edwards-Jones authored
Memoize Milestoneish#issues_visible_to_user and counts to reduce lookups Milstoneish SQL optimised with project, but still slow on GlobalMilestone
-
- 02 Dec, 2016 1 commit
-
-
Oswaldo Ferreira authored
-
- 23 Nov, 2016 1 commit
-
-
Valery Sizov authored
-
- 07 Oct, 2016 1 commit
-
-
Nick Thomas authored
This commit adds a number of _html columns and, with the exception of Note, starts updating them whenever the content of their partner fields changes. Note has a collision with the note_html attr_accessor; that will be fixed later A background worker for clearing these cache columns is also introduced - use `rake cache:clear` to set it off. You can clear the database or Redis caches separately by running `rake cache:clear:db` or `rake cache:clear:redis`, respectively.
-
- 30 Sep, 2016 1 commit
-
-
Makoto Scott-Hinkle authored
Updating test value for milestone title Adding API test for title with reserved HTML characters. Updating changelog Adding the MR number for fixing bug #22452. removing duplicate line Updating MR number.
-
- 27 Sep, 2016 1 commit
-
-
Makoto Scott-Hinkle authored
Updating test value for milestone title Adding API test for title with reserved HTML characters. Updating changelog Adding the MR number for fixing bug #22452. removing duplicate line Updating MR number.
-
- 01 Jul, 2016 1 commit
-
-
James Lopez authored
-
- 29 Jun, 2016 1 commit
-
-
James Lopez authored
-
- 03 Jun, 2016 2 commits
-
-
James Lopez authored
This reverts commit 3e991230.
-
James Lopez authored
# Conflicts: # app/models/project.rb
-
- 19 May, 2016 1 commit
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 16 May, 2016 2 commits
-
-
Sean McGivern authored
Postgres only needs to select a single column, so that can used as a sub-query where `Milestone.upcoming_ids_by_projects` is actually used in `IssuableFinder`. MySQL needs to select the `due_date` column because it's used in the `HAVING` clause, so it has to return an array of IDs.
-
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).
-
- 09 May, 2016 2 commits
-
-
Jeroen van Baarsen authored
In 8278b763 the default behaviour of annotation has changes, which was causing a lot of noise in diffs. We decided in #17382 that it is better to get rid of the whole annotate gem, and instead let people look at schema.rb for the columns in a table. Fixes: #17382
-
Felipe Artur authored
-
- 06 May, 2016 1 commit
-
-
Zeger-Jan van de Weg authored
-
- 05 May, 2016 1 commit
-
-
Felipe Artur authored
-
- 21 Apr, 2016 3 commits
-
-
Alejandro Rodríguez authored
The changes also account for %2.1. being matched as milestone_name = "2.1" without the word-separating dot.
-
Alejandro Rodríguez authored
Also, addint a suffix to the reference text when the milestone is in another project
-
Alejandro Rodríguez authored
Using the syntax proposed in #13829 [project_reference]%(milestone_id | milestone_name) to get a link to the referred milestone.
-