- 16 May, 2016 40 commits
-
-
Lin Jen-Shin authored
-
Lin Jen-Shin authored
-
Lin Jen-Shin authored
-
Lin Jen-Shin authored
-
Lin Jen-Shin authored
-
Lin Jen-Shin authored
sent_notification.project would never be nil, and we also have already checked message_project before entering process_create_issue.
-
Lin Jen-Shin authored
-
Lin Jen-Shin authored
-
Lin Jen-Shin authored
-
Lin Jen-Shin authored
-
Lin Jen-Shin authored
-
Lin Jen-Shin authored
-
Lin Jen-Shin authored
So we extend Gitlab::Email::Receiver for this new behaviour, however we might want to split it into another class for better testing it. Another issue is that, currently it's using this to parse project identifier: Gitlab::IncomingEmail.key_from_address Which is using: Gitlab.config.incoming_email.address for the receiver name. This is probably `reply` because it's used for replying to a specific issue. We might want to introduce another config for this, or just use `reply` instead of `incoming`. I'll prefer to introduce a new config for this, or just change `reply` to `incoming` because it would make sense for replying to there, too. The email template used in tests were copied and modified from: `emails/valid_reply.eml` which I hope is ok.
-
Lin Jen-Shin authored
-
Douwe Maan authored
Toggle email signup confirmation in admin settings Implements toggling verification email #14684 See merge request !3862
-
Douwe Maan authored
Add an Event's target's title to its reference link Given an activity feed entry like: > Douwe Maan commented on [issue #123] at [gitlab-org/gitlab-ce] ...the `issue #123` link will now have a `title` attribute. Plus some minor refactorings, see individual commits for details. See merge request !4090
-
Douwe Maan authored
Disallow search engines from indexing uploads from a GitLab project. This can sometimes include sensitive information from private projects and confidential issues. It shouldn't be indexed. Resolves #15551. cc: @DouweM See merge request !4167
-
Rémy Coutable authored
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
-
Rémy Coutable authored
Add tests for unintentional filtering bug in MR !3872 has a lack of tests for Merge Requests while !3872 has only ones for Issues. This MR has complementary tests for MR list. See merge request !4154
-
Connor Shea authored
This can sometimes include sensitive information from private projects and confidential issues. It shouldn't be indexed. Resolves #15551.
-
Felipe Artur authored
-
Robert Speicher authored
Remove unused methods from Event model
-
Robert Speicher authored
-
Robert Speicher authored
-
Robert Speicher authored
These get escaped automatically.
-
Robert Speicher authored
Prior, the `title` attribute was being included as an argument to the route helper rather than as an argument to `link_to`.
-
Robert Speicher authored
-
Robert Speicher authored
Given an activity feed entry like: > Douwe Maan commented on [issue #123] at [gitlab-org/gitlab-ce] ...the `issue #123` link will now have a `title` attribute.
-
Douwe Maan authored
Merge branch '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
-
Robert Speicher authored
Merge branch '13691-allow-admin-to-reset-user-password-and-force-password-reset-on-next-login' into 'master' Force password change after admin reset Closes #13691. See merge request !4016
-
Felipe Artur authored
-
Felipe Artur authored
-
Felipe Artur authored
-
Felipe Artur authored
-
Douwe Maan authored
Added authentication service for docker registry This adds a simple authentication service for docker which uses current user credentials to authenticate pulls and pushes. I have only one concern. Since the `.docker/config` is unencrypted, thus the password for user stored there is unencrypted, maybe we should from the start implement function to generate/provide a separate password just for the purposes of accessing docker registry? What do you think @jacobvosmaer @sytses @marin? cc @marin See merge request !3787
-
Douwe Maan authored
-
Kamil Trzcinski authored
-
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).
-
Sean McGivern authored
- Don't do setup in spec bodies. - Don't `describe` a symbol. - Don't use 'should'.
-