| Age | Commit message (Collapse) | Author |
|---|
|
This refactors the DashboardGroupMilestone model so that it no
longer uses the MilestoneFinder, instead using methods defined
on the Milestone model directly.
|
|
We should sort by title because name is only an alias for
the title attribute on the milestone model.
|
|
|
|
|
|
|
|
|
|
|
|
Group milestones can only be referred to by name, not IID. They also do not
support cross-project references.
|
|
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
services: true, no_db: true, api: true
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
|
|
|
|
|
|
|
|
Removed `Milestone#is_empty?` because is not used anymore in the codebase
|
|
|
|
|
|
Issue#visible_to_user moved to IssuesFinder
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/24637.
See merge request !2039
|
|
|
|
|
|
in db as unescaped.
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.
|
|
|
|
|
|
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.
|
|
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).
|
|
Remove the annotate gem and delete old annotations
In 8278b763d96ef10c6494409b18b7eb541463af29 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
/cc @yorickpeterse
See merge request !4099
|
|
In 8278b763d96ef10c6494409b18b7eb541463af29 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
|
|
|
|
|
|
|
|
|
|
Fixes #3903
|
|
|
|
This cuts down the time it takes to sort issues of a milestone by about
10x. In the previous setup the code would run a SQL query for every
issue that had to be sorted. The new setup instead runs a single SQL
query to update all the given issues at once.
The attached benchmark used to run at around 60 iterations per second,
using the new setup this hovers around 600 iterations per second. Timing
wise a request to update a milestone with 40-something issues would take
about 760 ms, in the new setup this only takes about 130 ms.
Fixes #3066
|
|
|
|
|
|
The percent_complete method returns a value of 100 when a
ZeroDivisionError occurs. That seems like a very strange default for an
error case, and results in a bug when a milestone has no corresponding
issues (new, empty milestones show 100% completion). This commit changes
the rescue value to 0, and subsequently fixes #1656, which reported this
problem.
|
|
Signed-off-by: Jeroen van Baarsen <jeroenvanbaarsen@gmail.com>
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
