+ Move 'Edit Project/Group' out of membership-related partial
+ Show the access request buttons only to logged-in users
+ Put the request access buttons out of in a more visible button
+ Improve the copy in the #remove_member_message helper
Signed-off-by: Rémy Coutable <remy@rymai.me>
Allow users to create confidential issues in private projects
Closes#14787
## What does this MR do?
Allow users to create confidential issues in private projects, and exclude access to them to project members with `Guest` role.
## Are there points in the code the reviewer needs to double check?
The query generated by the `User#authorized_projects` method.
## Why was this MR needed?
Community have been requesting this feature.
## What are the relevant issue numbers?
https://gitlab.com/gitlab-org/gitlab-ce/issues/14787https://gitlab.com/gitlab-org/gitlab-ce/issues/3678
## Screenshots (if relevant)
Not relevant.
## Todo
- [x] Allow users to create confidential issues in private projects
- [x] Project members with `Guest` role should not have access to confidential issues
- [ ] ~~Apply changes in EE + Elasticsearch~~ Will be done in another MR, when this got merged
See merge request !3471
If one had configured a `teamcity_url` like http://foo.bar/teamcity in
the previous implementation the plugin directed it's request i.e. to
http://foo.bar/httpAuth/... instead of http://foo.bar/teamcity/httpAuth/...
`URI.join` only works correctly, if the prefix URL has
- at least one or more trailing '/'
- the appended parts are _not_ prefixed with '/'
The current implementation should work with all sorts of TeamCity base
URLs.
Signed-off-by: Rémy Coutable <remy@rymai.me>
If one had configured a `bamboo_url` like http://foo.bar/bamboo in the
previous implementation the plugin directed it's request i.e. to
http://foo.bar/rest/... instead of http://foo.bar/bamboo/rest/...
`URI.join` only works correctly, if the prefix URL has
- at least one or more trailing '/'
- the appended parts are _not_ prefixed with '/'
The current implementation should work with all sorts of Bamboo base URLs.
Signed-off-by: Rémy Coutable <remy@rymai.me>
This improves the Bamboo Service and provides a fix for situations,
where the build trigger won't work, because Bamboo is requiring
authentication also for the trigger GET.
The change now does provide additional HTTP Basic Auth parameters
if user credentials were provided and appends an request parameter
indicating the HTTP Basic Authentication should be used.
This aligns interaction with Bamboo with the other calls this service
executes.
Signed-off-by: Rémy Coutable <remy@rymai.me>
Add Project.where_paths_in
In https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4410 I'm working on reducing the SQL queries needed to render Markdown. One reason for the large amount of queries is executing a large number of queries needed to find projects and related data. Basically `Project.find_with_namespace` is called in a loop and then any relations have to be retrieved separately.
By using `Project.where_paths_in` we can work around this by doing something like:
```ruby
project_paths = [...] # populated by some method
projects = Project.where_paths_in(project_paths).includes(:namespace, ...)
```
Ref: https://gitlab.com/gitlab-org/gitlab-ce/issues/18042
See merge request !4535
This method can be used to find multiple projects for multiple paths.
For example, take this snippet:
Project.where_paths_in(%w{gitlab-org/gitlab-ce gitlab-org/gitlab-ee})
This will return an ActiveRecord::Relation containing the GitLab CE and
GitLab EE projects.
This method takes care of matching rows both case-sensitively and
case-insensitively where needed.
Project.find_with_namespace in turn has been modified to use
Project.where_paths_in without nuking any scoping (instead it uses
reorder(nil)). This means that any default scopes (e.g. those used for
"pending_delete" stay intact).
The method Project.where_paths_in was added so the various Markdown
filters can use a single query to grab all the projects referenced in a
set of documents, something Project.find_with_namespace didn't allow.
Fix UTF-8 handling in incremental trace update API
## What does this MR do?
This MR fixes invalid UTF-8 handling in incremental trace update API (used by GitLab Runner).
## Why was this MR needed?
Current version is using `.length` method to determine current trace size where Runner is using the trace size in bytes. Also this byte size is used in headers and file operations to agree the trace part to send. This is a problem when build trace contains any multi-byte UTF-8 characters. This MR is fixing this situation so all parts are using the same size in bytes.
### Runner -> API communication before fix:
```
Checking for builds... received runner=_token_
gitlab-ci-multi-runner 1.3.0~beta.26.gcfd63b9 (cfd63b9) build=25 runner=_token_
Using Docker executor with image debian:jessie ... build=25 runner=_token_
Pulling docker image debian:jessie ... build=25 runner=_token_
25 Submitting build to coordinator... ok runner=_token_
25 Appending trace to coordinator... ok RemoteRange=0-158 RemoteState=running ResponseMessage=202 Accepted ResponseStatusCode=202 SentRange=0-158 runner=_token_
25 Appending trace to coordinator... ok RemoteRange=0-491 RemoteState=running ResponseMessage=202 Accepted ResponseStatusCode=202 SentRange=158-505 runner=_token_
WARNING: 25 Appending trace to coordinator... range missmatch RemoteRange=0-491 RemoteState= ResponseMessage=416 Requested Range Not Satisfiable ResponseStatusCode=416 SentRange=505-584 runner=_token_
WARNING: 25 Resending trace patch due to range missmatch runner=_token_
25 Appending trace to coordinator... ok RemoteRange=0-556 RemoteState=running ResponseMessage=202 Accepted ResponseStatusCode=202 SentRange=491-584 runner=_token_
WARNING: 25 Appending trace to coordinator... range missmatch RemoteRange=0-556 RemoteState= ResponseMessage=416 Requested Range Not Satisfiable ResponseStatusCode=416 SentRange=584-663 runner=_token_
WARNING: 25 Resending trace patch due to range missmatch runner=_token_
25 Appending trace to coordinator... ok RemoteRange=0-621 RemoteState=running ResponseMessage=202 Accepted ResponseStatusCode=202 SentRange=556-663 runner=_token_
Build succeeded build=25 runner=_token_
WARNING: 25 Appending trace to coordinator... range missmatch RemoteRange=0-621 RemoteState= ResponseMessage=416 Requested Range Not Satisfiable ResponseStatusCode=416 SentRange=663-797 runner=_token_
WARNING: 25 Resending trace patch due to range missmatch runner=_token_
25 Appending trace to coordinator... ok RemoteRange=0-741 RemoteState=running ResponseMessage=202 Accepted ResponseStatusCode=202 SentRange=621-797 runner=_token_
25 Submitting build to coordinator... ok runner=_token_
```
### Runner -> API communication after fix:
```
Checking for builds... received runner=_token_
gitlab-ci-multi-runner 1.3.0~beta.26.gcfd63b9 (cfd63b9) build=26 runner=_token_
Using Docker executor with image debian:jessie ... build=26 runner=_token_
Pulling docker image debian:jessie ... build=26 runner=_token_
26 Submitting build to coordinator... ok runner=_token_
26 Appending trace to coordinator... ok RemoteRange=0-158 RemoteState=running ResponseMessage=202 Accepted ResponseStatusCode=202 SentRange=0-158 runner=_token_
26 Appending trace to coordinator... ok RemoteRange=0-505 RemoteState=running ResponseMessage=202 Accepted ResponseStatusCode=202 SentRange=158-505 runner=_token_
26 Appending trace to coordinator... ok RemoteRange=0-584 RemoteState=running ResponseMessage=202 Accepted ResponseStatusCode=202 SentRange=505-584 runner=_token_
26 Appending trace to coordinator... ok RemoteRange=0-663 RemoteState=running ResponseMessage=202 Accepted ResponseStatusCode=202 SentRange=584-663 runner=_token_
Build succeeded build=26 runner=_token_
26 Submitting build to coordinator... ok runner=_token_
```
See merge request !4541
Add a new application setting, after_sign_up_text. This is text to be
rendered as Markdown and shown on the 'almost there' page after a user
signs up, but before they've confirmed their account.
Tweak the styles for that page so that centered lists look reasonable.
This was not a clear cut n+1 query, given that if you're directly subscribed to all issues
that the API is returning you never really need to check for the notes. However, if you're
subscribed to _all_ of them, then for each issuable you need to go once to `notes`, and
once to `users` (for the authors). By preemtively loading notes and authors, at worst you have
1 extra query, and at best you saved 2n extra queries. We also took advantage of this preloading
of notes when counting user notes.
`notes_with_associations` are used for `participant` declarations, but `Participable`
only really cares about the target entity project, and not the participants
projects.
`notes_with_associations` are also used in `Commit::has_been_reverted?` which
employs the reference extractor of the commit, so no references to the notes
projects are made there (`Mentionable::all_references` cares only about the
`author` and other `attr_mentionable`). A paralel situation occurs on
`Issue::referenced_merge_requests`.
Notifications dropdown on project page now has descriptions
## What does this MR do?
Adds descriptions to the notification settings dropdown on project pages. Also changed the order of them to make more sense.
## What are the relevant issue numbers?
Part of #12758
## Screenshots (if relevant)
See merge request !4374
Douwe Maan
Rémy Coutable
David AlexanderandRémy Coutable
Kamil Trzcinski
Douwe Maan
Benjamin SchmidandRémy Coutable
Douglas Barbosa Alexandre
Robert Speicher
Felipe Artur
Paco GuzmanandYorick Peterse
Rui AndersonandRémy Coutable
Tomasz Maczukin
Sean McGivern
Alejandro Rodríguez
Jacob Schatz
Jacob Vosmaer (GitLab)
Thijs WoutersandAlfredo Sumaran