| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| | |
Toggle email signup confirmation in admin settings
Implements toggling verification email #14684
See merge request !3862
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Use the relative url prefix for links in Wiki
Retry of gitlab-org/gitlab-ce!4026
@rymai !4050 solved all other problems how it looks like. I [tested](https://gitlab.com/artem-forks/gitlab-ce/commit/ff01eca7b559efa7cacf3412aa01cd8ae8a6db7e/builds) this with ruby22
Fixes #17071
See merge request !4131
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
'17227-upcoming-milestone-is-confusing-when-projects-have-different-milestones' into 'master'
Make upcoming milestone work across projects
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).
Closes #17227.
See merge request !4125
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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).
|
|\ \ \
| |/ /
|/| | |
|
| |/ |
|
| | |
|
| | |
|
|/ |
|
| |
|
|
|
|
| |
Closes #15638
|
|
|
|
|
|
| |
no omniauth provider enabled
This will fix failing tests in case gitlab.yml file has no omniauth providers enabled
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
Improve documentation and web test for web hooks
Tips and documentation of actual hook behavior. Improved user feedback
when testing hooks via the web UI.
See merge request !4015
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`User#starred_projects` doesn't perform any visibility checks. This has
a couple of problems:
1. It assumes a user can always view all of their starred projects in
perpetuity (project not changed to private, access revoked, etc.).
2. It assumes that we'll only ever allow a user to star a project they
can view. This is currently the case, but bugs happen.
Add `User#viewable_starred_projects` to filter the starred projects by
those the user either has explicit access to, or are public or
internal. Then use that in all places where we list the user's starred
projects.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Revert "Merge branch 'wiki-fix' into 'master'"
This reverts commit 4cc85a58e8ca00f5a4ecbd2bca40a0cad867b817 (!4026), reversing
changes made to 90ae445ba930068d04adc5a009dbdeabe4cb3e34.
From https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4026#note_11719950:
> 1. On Ruby 2.1.x, the [`uri.path = ::File.join(project_wiki_base_path, uri.path)`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/banzai/filter/wiki_link_filter.rb#L39) raises an `URI::InvalidComponentError: bad component(expected relative path component): http://bar.com/baz` error in `Banzai::Filter::WikiLinkFilter#rebuild_wiki_uri`, which is then rescued in [`Banzai::Filter::WikiLinkFilter#process_link_attr`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/banzai/filter/wiki_link_filter.rb#L34), thus the link is not modified and the tests pass.
1. On Ruby 2.2.x, the same line doesn't raise an error anymore, thus tests are broken on Ruby 2.2 only. I didn't really understand yet why having absolute links in the wiki would break some tests vs having relative links as before, but I think the safest course to action is to revert this MR and to find another fix (probably just prepending `ProjectWiki#wiki_base_path` with the relative URL path component if we are in the case of a relative URL...
/cc @artem-sidorenko
Just a FYI note: no need to pick into `8-7-stable` since the original commit was not picked.
See merge request !4105
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit 4cc85a58e8ca00f5a4ecbd2bca40a0cad867b817, reversing
changes made to 90ae445ba930068d04adc5a009dbdeabe4cb3e34.
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | | |
Sanitize milestones and labels titles
fixes #15394
See merge request !4046
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Use the proper GitLab URL for links in Wiki
Fixes gitlab-org/gitlab-ce#17071
wiki links are proper compiled, e.g.
```
[same-level](same-level) -> <a href="same-level">same-level</a>
[sub-level](sub/level) -> <a href="sub/level">sub-level</a>
[upper-level](../upper-level) -> <a href="../upper-level">upper-level</a>
```
See merge request !4026
|
| |/ / |
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Use Rugged's TagCollection#create instead of gitlab-shell's Repository#add_tag for better performance
This was originally opened at !1757 by @pcarranza but I changed it to use Rugged instead of gitlab_git, following @DouweM's request.
Once this is merged, https://gitlab.com/gitlab-org/gitlab-shell/merge_requests/26 will be mergeable too.
See merge request !3745
|
| | |
| | |
| | |
| | | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |/
| |
| |
| |
| |
| | |
Repository#add_tag for better performance
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|\ \
| |/
|/|
| |
| | |
# Conflicts:
# Gemfile.lock
|
| |
| |
| | |
- Parameter validation as ISO8601 format
|
|\ \ |
|
| | |
| | |
| | |
| | | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
This changes Project#protected_branch? to use a query to check if a
branch is protected, instead of loading all ProtectedBranch records into
memory just to check if the list of names includes a given branch name.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is a combination of 3 commits.
- Update the bare repositories info/attributes if the default branch is updated
- Check the diff attributes of a file before showing a diff
- Update CHANGELOG
|
| | | |
|
| | | |
|
| | | |
|
| |/
|/|
| |
| |
| | |
This status will be returned only when there are no failed jobs
that are not allowed to fail.
|
| |
| |
| |
| |
| |
| |
| |
| | |
"CHANGELOG", "NEWS", "HISTORY", and "CHANGES" are recognized as Changelog files.
Also adds relevant tests for each of these names.
Resolves #14864.
|
|/
|
|
| |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
|
|
| |
Closes gitlab-org/gitlab-ee#506
|
|
|
|
|
|
| |
Fixes #15470.
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|\
| |
| |
| |
| |
| |
| | |
Filter labels by including ALL filter titles
Fixed query to use `AND` and not `OR`. Refactored relevant specs
See merge request !3815
|
| | |
|
| | |
|