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
Restrict starred projects to viewable ones
`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.
Closes#17249.
See merge request !4108
Only generate repository push email once
The repository push email can be very expensive to generate, especially
with syntax-highlighted diffs. Instead of generating the email for each
recipient, generate one email object and reset the Message-Id and To
headers for each recipient. (Cloning would also be expensive in the case
of large emails, although probably not as bad as generating from
scratch.)
Closes#17270.
See merge request !4070
The repository push email can be very expensive to generate, especially
with syntax-highlighted diffs. Instead of generating the email for each
recipient, generate one email object and reset the Message-Id and To
headers for each recipient. (Cloning would also be expensive in the case
of large emails, although probably not as bad as generating from
scratch.)
`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.
Support multi-line tag messages
_Originally opened at !2853 by @clns._
- - -
Tag messages in Git can include a short summary of what changes are included in a release and any other relevant information. So I think GitLab should support multi-line tag messages, both in the "New Tag" interface and when viewing the tag.
Also a non-technical user could use GitLab's interface to create releases, but at the moment this is impossible because he cannot enter a multi-line message. This would've been very handy, otherwise he would need to do it from the command line or other GUI program, which is not something a non-technical user has access to or knows how to do.
This merge request adds support for multi-line tag messages. Below are the impacted screens. Let me know if I should change anything.
This would close#3690 and #2460
See merge request !3833
- Fix naming of API::CommitStatuses
- Ensure we use require_dependency instead of require
- Ensure the namespace is right in lib/api/api.rb, otherwise, we
might require Grape::API::Helpers which defines the `#params` method.
This is to avoid requiring a file multiple times and getting an "Already
initialized constant" error.
Signed-off-by: Rémy Coutable <remy@rymai.me>
Revert "Merge branch 'wiki-fix' into 'master'"
This reverts commit 4cc85a58e8 (!4026), reversing
changes made to 90ae445ba9.
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
Remove the annotate gem and delete old annotations
In 8278b763d9 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 8278b763d9 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
API: Expose Issue#user_notes_count and MergeRequest#user_notes_count
_Originally opened at !2954 by @cnam812._
- - -
Expose `Issue#user_notes_count` and `MergeRequest#user_notes_count` through the API.
See merge request !3126
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
Fix build notification on merge request page change even if the build status didn't change
## What does this MR do?
This MR contains a bugfix for #17357 which was introduced by !3998. The notification are now only shown on status changes, and not when switching between different merge requests.
## Are there points in the code the reviewer needs to double check?
Check implementation
## Why was this MR needed?
Because auf a bug introduced in !3998.
## What are the relevant issue numbers?
#17357Closes#17357
See merge request !4086
Use a custom Loofah scrubber since sanitize 2.x transformers are inadequate
to handle case-sensitive SVG attributes. sanitize parses documents as HTML
instead of XML, which causes all SVG attribute names (e.g. viewBox) to be downcased.
* SVG element list: https://www.w3.org/TR/SVG/eltindex.html
* SVG attribute list: https://www.w3.org/TR/SVG/attindex.htmlCloses#14555
Auto-set title for branches created from issues
This sets the title for a new MR to 'Resolves "$issue-title"' when:
- The source branch for the MR begins with a value iid.
- The MR has more than one commit in its diff (if there's one commit, keep using the commit's first line).
- The iid does not point to a confidential issue.
Single commit:
Multiple commits:
Confidential issue:
cc @DouweM @zj
Closes#14564
See merge request !3966
If a branch starts with an issue's IID, followed by a hyphen, the
description will be updated to say that is closes the issue. This also
updates the title of the merge request to 'Resolves "$issue-title"', as
long as:
- There is more than one commit in the merge request (if there is only
one commit, the commit's title will be used as before)
- The issue's IID is valid for the project
Timothy Andrew
Douwe Maan
Robert Speicher
Sean McGivern
Long Nguyen
Rémy Coutable
Grzegorz Bizon
Dmitriy Zaporozhets
Yorick Peterse
Stan Hu
Jeroen van Baarsen
cnam-depandRémy Coutable
Jacob Vosmaer
Artem Sidorenko
Robert Speicher
Benedikt Huss
Ahmad Sherif
Takuya Noguchi