Fix hooks for web based events with external issue references
The creation of cross references for external issues (which would fail)
is now prevented. This fixes a 500 error and the execution of hooks when
creating a merge request or commenting on one.
Fixes#1650, GH-9333.
This regression might have been introduced by
8f8a8ab32b. There is actually a TODO by
@rspeicher mentioning external issues which is lost (unhandled) in a
later commit.
This fix is related to !766 and !804 which fix a similar issue for hooks for
Git based events.
See merge request !794
Fix post-receive errors on a push when an external issue tracker is configured
### What does this MR do?
This MR improves upon !766, fixing errors upon a git push that occur only when an external issue tracker (not JIRA) is used. This MR takes into account that external issue trackers, such as JIRA, may close issues. Disabling the processing of post-receive commits when an external issue tracker is configured seems like the wrong behavior.
### Why was this MR needed?
When a user adds an issue reference, the refactoring in 8f8a8ab and a6defd157 caused `project.get_issue` to be called, causing `ExternalIssue` to be returned when an external issue tracker was configured. This object does not have a `close` method, as needed in `CloseService`. Nor does it make sense to associate a `SystemNote` with this object.
GitLab EE uses a [special case for JIRA](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/app/services/git_push_service.rb#L87). I would recommend moving this logic into `CloseService` too.
### What are the relevant issue numbers?
* Closes#1700
* Closes#1720
See merge request !804
Add to_reference method to referable models
Now there is a single source of information for which attribute a model uses to be referenced, and its special character.
See merge request !641
In an empty repository, pushing a new branch not called "master" would
leave HEAD in an unknown state, causing ambiguity if another branch
were pushed. This could in turn cause a new protected branch to be
created and cause the default branch to change.
* Closes#1561
* Closes#1576
* Closes https://github.com/gitlabhq/gitlabhq/issues/8883
Support configurable attachment size in Application Settings page
### What does this MR do?
This MR provides the ability to configure the maximum size of an attachment inside a note. A parameter has been added to the Application Settings page.
### Are there points in the code the reviewer needs to double check?
What should be done with the legacy note attachment validation? I added code to make the validation work with the configurable setting. I could see an issue where an admin lowers the limit from 10 megabytes to 5 megabytes, which could cause an existing model to be invalid.
### Why was this MR needed?
We often have attachments that exceed 10 MB, and it would be nice to be able to override the defaults.
### What are the relevant issue numbers / [Feature requests](http://feedback.gitlab.com/)?
See Issue #1258
### Screenshots
Before:
After:
See merge request !407
Restricted visibility levels - bug fix and new feature
This allows admin users to override restricted visibility settings when creating and updating projects and snippets, and moves the restricted visibility configuration from gitlab.yml to the web UI. See #1903.
## Move configuration location
I added a new section to the application settings page for restricted visibility levels. Each level has a checkbox, styled with Bootstrap to look like a toggle button. A checked box means that the level is restricted. I added a glowing text shadow and changed the background color for checked buttons because the default styles made it hard to distinguish between checked and unchecked. This image shows the new section with the "Public" box checked:
## Allow admins to override
To allow admin users to override the restricted visibility levels, I had to remove the `visibility_level` validation from the `Project` class. The model doesn't know about the `current_user`, which should determine whether the restrictions can be overridden. We could use the creator in the validation, but that wouldn't work correctly for projects where a non-admin user is the creator and an admin tries to change the project to a restricted visibility level.
The `Project::UpdateService` and `Project::CreateService` classes already had code to determine whether the current user is allowed to use a given visibility level; now all visibility level validation is done in those classes. Currently, when a non-admin tries to create or update a project using a restricted level, these classes silently set the visibility level to the global default (create) or the project's existing value (update). I changed this behavior to be more like an Active Model validation, where using a restricted level causes the entire request to be rejected.
Project and personal snippets didn't have service classes, and restricted visibility levels weren't being enforced in the model or the controllers. The UI disabled radio buttons for restricted levels, but that wouldn't be difficult to circumvent. I created the `CreateSnippetService` and `UpdateSnippetService` classes to do the same restricted visibility check that the project classes do. And since I was dealing with snippet visibility levels, I updated the API endpoints for project snippets to allow users to set and update the visibility level.
## TODO
* [x] Add more tests for restricted visibility functionality
cc @sytse @dzaporozhets
See merge request !1655
Dmitriy Zaporozhets
Stan Hu
Robert Speicher
Douwe Maan
Daniel Gerhardt
Arthur Gautier
Valery Sizov
Kamil Trzcinski
Dmitriy Zaporozhets
Vinnie Okada
