There was some confusion over whether `code` or `content` is the right
parameter for snippets. Internally, the database stores
`content`. However:
1. Project snippets use `code`. `code` gets remapped in `content` in
`lib/api/project_snippets.rb`.
2. Personal snippets use `content`.
To unify these APIs, allow an alias of `content` to work for project
snippets.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/66673
When a restricted visibility level of `private` is set in the instance,
creating a snippet with the `visibility` level would always fail.
This happened because:
1. `params[:visibility]` was a string (e.g. "public")
2. `CreateSnippetService` and `UpdateSnippetService` only looked
at `params[:visibility_level]`, which was `nil`.
To fix this, we:
1. Make `CreateSnippetService` look at the newly-built
`snippet.visibility_level`, since the right value is assigned by the
`VisibilityLevel#visibility=` method.
2. Modify `UpdateSnippetService` to handle both `visibility_level` and
`visibility` parameters.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/66050
Updates specs to use new rails5 format.
The old format:
`get :show, { some: params }, { some: headers }`
The new format:
`get :show, params: { some: params }, headers: { some: headers }`
Instead of exposing the VisibilityLevel as Integer, expose it as
String `visibility` for Project and ProjectSnippet.
Filter queries also accept the `visibility` as String instead of
`visibility_level` as Integer.
Also remove the `public` boolean.
Apply the same spam checks to public snippets (either personal snippets
that are public, or public snippets on public projects) as to issues on
public projects.
GitLab Bot
Grzegorz Bizon
Ash McKenzie
Rémy Coutable
Stan Hu
blackst0ne
Robert Schilling
Robert Speicher
Nick Thomas
Jacopo
Sean McGivern
Maxim Rydkin
James Lopez
Jarka Kadlecova
Toon Claes
Oswaldo Ferreira
Sean McGivern
Livier
Ben Boeckel
tiagonbotelho
Z.J. van de Weg