This attribute is since validated against `DynamicPathValidator`, which
has strict requirements for the characters allowed, and should no longer
need to be sanitized in a callback before saving.
This has additional benefits in our test suite, where every creation of
a `User` record was calling `Sanitize.clean` on a username value that
was always clean, since we're the ones generating it.
The method User#projects_limit_left would run "personal_projects.count"
but such a query is not memoized. As a result multiple calls to
User#projects_limit_left would result in multiple COUNT(*) queries being
executed.
To work around this this commit adds User#personal_projects_count which
simply memoizes the result of the COUNT(*) in an instance variable.
The "events" table has a foreign key on "events.project_id" with a
cascading delete. As such it's impossible for an event to have a
non-existing project ID.
When sign-in is disabled:
- skip password expiration checks
- prevent password reset requests
- don’t show Password tab in User Settings
- don’t allow login with username/password for Git over HTTP requests
- render 404 on requests to Profiles::PasswordsController
This is allowed for existing instances so we don't end up 76 offenses
right away, but for new code one should _only_ use this if they _have_
to remove non database data. Even then it's usually better to do this in
a service class as this gives you more control over how to remove the
data (e.g. in bulk).
This allows to enable/disable a feature flag for a given user, or a
given Flipper group (must be declared statically in the `flipper.rb`
initializer beforehand).
Signed-off-by: Rémy Coutable <remy@rymai.me>
If internal auth is disabled and user is not an LDAP user, present
the user with an alert to create a personal access token if he does
not have one already.
In CE only the admin has access to all private groups & projects. In EE also an
auditor can have full private access.
To overcome merge conflicts, or accidental incorrect access rights, abstract
this out in `User#full_private_access?`.
`User#admin?` now only should be used for admin-only features. For private
access-related features `User#full_private_access?` should be used.
Backported from gitlab-org/gitlab-ee!2199