# Conflicts:
#	app/controllers/concerns/internal_redirect.rb
#	app/services/application_settings/update_service.rb
#	db/schema.rb
#	doc/administration/index.md
#	doc/api/settings.md
#	locale/gitlab.pot

[ci skip]

Enforce application wide terms

Closes #44798

See merge request gitlab-org/gitlab-ce!18570

[EE] Enforce application wide terms

See merge request gitlab-org/gitlab-ee!5529

Make empty state copy aware of applied filters in Epics list and Roadmap view

See merge request gitlab-org/gitlab-ee!5465

AutoDevOps Docs fix invalid external link

Closes #46056

See merge request gitlab-org/gitlab-ce!18748

Ignore knapsack and rspec_flaky

See merge request gitlab-org/gitlab-ce!18747

Resolve "ee-specific-lines-check should not check against CE master"

Closes #5869

See merge request gitlab-org/gitlab-ee!5564

Backport IdentityLinker#failed? from GroupSaml callback flow

See merge request gitlab-org/gitlab-ce!18749

Ensure when accessing Rails, we really get ::Rails (and not Sidekiq::Rails)

See merge request gitlab-org/gitlab-ce!18730

See https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/5572

Merge branch '4957-projectsyncworker-should-skip-projects-that-have-a-broken-gitaly-shard' into 'master'

Resolve "ProjectSyncWorker should skip projects that have a broken Gitaly shard"

Closes #4957

See merge request gitlab-org/gitlab-ee!5514

Merge branch '4957-projectsyncworker-should-skip-projects-that-have-a-broken-gitaly-shard-3' into 'master'

Shard name vs. Shard updates, general tech debt cleanup

Closes #4957

See merge request gitlab-org/gitlab-ee!5555

Replace commits spinach tests with RSpec analog

See merge request gitlab-org/gitlab-ce!18743

If CE master is ahead of EE master, and the CE branch
was forked from CE master, then the CE branch would
contain a lot of changes which aren't presented in EE master,
therefore they're not presented in EE branch, either.

In this case, we need to remove the commits from CE master
which aren't merged into EE yet. So we want to rebase CE branch
onto CE/EE merge base, with ce_fetch_base and ce_fetch_head,
where ce_fetch_base is the merge base of CE master and CE branch,
and ce_fetch_head is the original HEAD of CE branch.

This should make sure there's no extra commits involved.

The only way it could fail would be conflicts during rebase,
which ideally should not happen at all. This doesn't mean
it's impossible to happen, but given the reason we make the CE branch,
it should only contain minimum changes from EE to CE, which shouldn't
conflict.

Let's try this and see and investigate if conflicts happen.

Add note about rebase/squash duplication in Gitaly

See merge request gitlab-org/gitlab-ce!18741

Since we're not showing system footer and header on these pages, we
should not add margin when they are enabled

`InternalRedirect` prevents Open redirect issues by only allowing
redirection to paths on the same host.

It cleans up any unwanted strings from the path that could point to
another host (fe. //about.gitlab.com/hello). While preserving the
querystring and fragment of the uri.

It is already used by:

- `TermsController`
- `ContinueParams`
  - `ImportsController`
  - `ForksController`
- `SessionsController`: Only for verifying the host in CE. EE allows
   redirecting to a different instance using Geo.

This enforces the terms in the web application. These cases are
specced:

- Logging in: When terms are enforced, and a user logs in that has not
  accepted the terms, they are presented with the screen. They get
  directed to their customized root path afterwards.
- Signing up: After signing up, the first screen the user is presented
  with the screen to accept the terms. After they accept they are
  directed to the dashboard.
- While a session is active:
  - For a GET: The user will be directed to the terms page first,
    after they accept the terms, they will be directed to the page
    they were going to
  - For any other request: They are directed to the terms, after they
    accept the terms, they are directed back to the page they came
    from to retry the request. Any information entered would be
    persisted in localstorage and available on the page.

When a user accepts, we store this in the agreements to keep track of
which terms they accepted. We also update the flag on the user.

This will act as a cache, otherwise we would need to load the
`term_agreements` for a user on each request.

Using this field the result we're interested in is loaded when the
current user is loaded, without causing an extra query.

When terms are present, they can be viewed on `/-/users/terms`.

We will reuse the the dropdown, but exclude some menu items based on
permissions.

So moving the menu to a partial, and adding checks for each menu item here.