Jan Provaznik authored 5 years ago and Thong Kuah committed 5 years ago

Creates new event when an epic is created, closed, reopened or
commented.

Etienne Baqué authored 5 years ago and Andreas Brandl committed 5 years ago

Modified schema via migrations.
Added one-to-one relationship between the two models.
Added changelog file

Giorgenes Gelatti authored 5 years ago and Thong Kuah committed 5 years ago

Extends the permission of $CI_REGISTRY_USER to allow them
to delete tags in addition to just pushing.

https://gitlab.com/gitlab-org/gitlab-ce/issues/40096

When updating group and project members, new system hooks
`user_update_for_group` and `user_update_for_team` will be executed.

Fixes https://gitlab.com/gitlab-org/gitlab-ee/issues/12252

Sean McGivern authored 5 years ago and Mayra Cabrera committed 5 years ago

The 'assigned' reason doesn't apply to notes, but the other two
can ('mentioned' and 'own_activity'), so we can still use this for note
emails.

Manoj M J authored 5 years ago and Mayra Cabrera committed 5 years ago

This change limits the number of emails
for new access requests notifications to
10 most recently active owners/maintainers

Feature flag has been defaulting to `true` since 12.2

Alexis Kalderimis authored 5 years ago and Thong Kuah committed 5 years ago

This allows the be_url matcher to be more specific. By default, it only
matches HTTP and HTTPS URIs.

João Cunha authored 5 years ago and Jan Provaznik committed 5 years ago

Extract duplicated code from two similar classes into a parent one.

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

Persists if a board list is collapsed for each user.

These services aren't specific to GCP, and will be used for AWS
as part of https://gitlab.com/gitlab-org/gitlab-ce/issues/46686

During a project import, `LfsLinkService` attempts to link `LfsObjects`
that have not already been associated with a project.  It's possible for
a large repo to have thousands of OIDs, which can cause long database
query and parsing times.  By processing a batch of 1000 at a time, we
can reduce that time at the expense of a few more SQL queries.

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/66274

Luke Duncalfe authored 5 years ago and Mayra Cabrera committed 5 years ago

Notes call `#after_note_created` and `#after_note_destroyed` on their
noteable in callbacks, so the noteable can perform tasks particular to
them, like cache expiry.

This is in preparation of the EE-specific class
`DesignManagement::Design` clearing its `user_notes_count` cache when
its note are created or destroyed.

Refactoring Rspec behaviour testing of a counter caching service into a
shared example.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13353

Code Review Usage Ping for Create SMAU

Call QuickActionsService on Note update

Add support for notes which just contain
commands after editing

Return http status gone (410) if note was deleted

Temporary frontend addition so it is not
failing when a note is deleted

Move specs to shared examples

Fix rubocop style issue

Deleting note on frontend when status is 410

Use guard clause for note which got deleted

Simplified condition for nil note

This method should no longer be called
with nil note

Refactoring of execute method to reduce
complexity

Move errors update to delete_note method

Note is now deleted visually when it only
contains commands after update

Add expectation

Fix style issues

Changing action to fix tests

Add tests for removeNote and update
deleteNote expectations

User images and videos will get proxied through
the Camo server in order to keep malicious
sites from collecting the IP address of users.

Reuben Pereira authored 5 years ago and Mayra Cabrera committed 5 years ago

Add to the service and migration both.

At present, the TodoService uses the `:read_project` ability to decide
whether a user can read a note on a commit. However, commits can have a
visibility level that is more restricted than the project, so this is a
security issue.

This commit changes the code to use the `:read_commit` ability in this
case instead, which ensures TODOs are only generated for commit notes
if the users can see the commit.

This makes BuildQueueService to force refresh runners
that are considered to have recent queue.

Such runners are the ones that connected within online
interval + time to expire runner cache.

This is a port from EE changes where
we introduce a new limit for Plan model.

https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1182

Adding, destroying and toggling emoji previously lacked services and
instead were performed through methods called on Awardable models.

This led to inconsistencies where relevant todos would be marked as done
only when emoji were awarded through our controllers, but not through
the API. Todos could also be marked as done when an emoji was being
removed.

Behaviour changes

- Awarding emoji through the API will now mark a relevant Todo as done
- Toggling an emoji off (destroying it) through our controllers will no
  longer mark a relevant Todo as done

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/63372

This finder class acts more as a service, as it only returns mapped
data.

Renaming this class allows us to create a new AwardEmojiFinder without
the ambiguity of there being two similarly-named finders.

https://gitlab.com/gitlab-org/gitlab-ce/issues/63372

changes: @user a Zoom call was added to this issue
into: @user added a Zoom call to this issue

Same concept appleis for "removed"

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31741 introduced
a regression where not all the right parameters would be passed into
`Ci::CreatePipelineService`. We fix this by breaking out the pipeline
parameters and reusing a method from `Gitlab::DataBuilder::Push`.

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/66196

Stan Hu authored 5 years ago and Douwe Maan committed 5 years ago

Previously `ProjectCacheWorker` would be scheduled once per ref, which
would generate unnecessary I/O and load on Sidekiq, especially if many
tags or branches were pushed at once. `ProjectCacheWorker` would expire
three items:

1. Repository size: This only needs to be updated once per push.
2. Commit count: This only needs to be updated if the default branch
   is updated.
3. Project method caches: This only needs to be updated if the default
   branch changes, but only if certain files change (e.g. README,
   CHANGELOG, etc.).

Because the third item requires looking at the actual changes in the
commit deltas, we schedule one `ProjectCacheWorker` to handle the first
two cases, and schedule a separate `ProjectCacheWorker` for the third
case if it is needed. As a result, this brings down the number of
`ProjectCacheWorker` jobs from N to 2.

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/52046

Instead of checking if a commit already exists in the upstream project
in its ProcessCommitWorker and bailing out if it does, we check the
existence of all commits in bulk in Git::BranchHooksService, so that we
can skip scheduling ProcessCommitWorker jobs for those commits
that already exist upstream entirely.

Nick Thomas authored 5 years ago and Mayra Cabrera committed 5 years ago

Prior to 12.1, rebase status was looked up directly from Gitaly. In
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14417 , a DB
column was added to track the status instead. However, we couldn't stop
looking at the gitaly status immediately, since some rebases may been
running across the upgrade.

Now that we're in 12.3, it is safe to remove the direct-to-gitaly
lookup. This also happens to fix a 500 error that is seen when viewing
an MR for a fork where the source project has been removed.

We still look at the Gitaly status in the service, just in case Gitaly
and Sidekiq get out of sync - I assume this is possible, and it's a
relatively cheap check.

Since we atomically check and set `merge_requests.rebase_jid`, we
should never enqueue two `RebaseWorker` jobs in parallel.

- Adds UI to configure in group and project settings
- Removes notification configuration for users when
disabled at group or project level

Add Gitlab::VisibilityLevelChecker that verifies
selected project visibility level (or overridden param)
is not restricted when creating or importing a project