Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
GitLab Community Edition
GitLab Community Edition
  • Project
    • Project
    • Details
    • Activity
    • Releases
    • Cycle Analytics
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
    • Locked Files
  • Issues 14,492
    • Issues 14,492
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 812
    • Merge Requests 812
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Charts
  • Registry
    • Registry
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • GitLab.org
  • GitLab Community EditionGitLab Community Edition
  • Issues
  • #30472

You need to sign in or sign up before continuing.
Closed
Open
Opened Apr 04, 2017 by Stan Hu@stanhu
  • Report abuse
  • New issue
Report abuse New issue

Inconsistent state between `Project#team.members` vs. `Project#project_members`

Project#project_members uses the members table, but Project#team.members uses the project_authorizations table. This can lead to an inconsistent state seen in gitlab-com/infrastructure#1486 where the user can see the project, but the admin cannot see that the user has access to the project. For example:

irb(main):015:0> ProjectAuthorization.where(user_id: user.id)
D, [2017-04-04T23:34:58.688574 #23742] DEBUG -- :   ProjectAuthorization Load (0.7ms)  SELECT "project_authorizations".* FROM "project_authorizations" WHERE "project_authorizations"."user_id" = $1  [["user_id", 843529]]
=> #<ActiveRecord::Relation [#<ProjectAuthorization user_id: 843529, project_id: 2010956, access_level: 40>, #<ProjectAuthorization user_id: 843529, project_id: 2333233, access_level: 40>]>
irb(main):004:0> project.team.members.map(&:username)
D, [2017-04-04T23:32:19.132321 #23742] DEBUG -- :   User Load (3.9ms)  SELECT "users".* FROM "users" INNER JOIN "project_authorizations" ON "users"."id" = "project_authorizations"."user_id" WHERE "project_authorizations"."project_id" = $1  ORDER BY "users"."id" DESC  [["project_id", 2333233]]
=> ["sam1", "lion1", "grac1", "zhang1", "ivant1", "cat1", "god1"]

I think running User#refresh_authorized_projects makes things consistent, but we should design the system so that is difficult or impossible to get into this state. For example, if we're going to update one thing, we should update both in a transaction.

Related issues

Assignee
Assign to
Epic
9.3
Milestone
9.3
Assign milestone
Time tracking
None
Due date
No due date
7
Labels
Next Patch Release P3 Platform [DEPRECATED] S3 reproduced on GitLab.com security user management
Assign labels
  • View project labels
Reference: gitlab-org/gitlab-ce#30472