BigW Consortium Gitlab

  1. 06 Jul, 2017 1 commit
  2. 30 Jun, 2017 8 commits
  3. 28 Jun, 2017 2 commits
  4. 26 Jun, 2017 1 commit
    • Allow unauthenticated access to the `/api/v4/users` API. · 20f679d6
      Timothy Andrew authored
      - The issue filtering frontend code needs access to this API for non-logged-in
        users + public projects. It uses the API to fetch information for a user by
        username.
      
      - We don't authenticate this API anymore, but instead - if the `current_user` is
        not present:
      
        - Verify that the `username` parameter has been passed. This disallows an
          unauthenticated user from grabbing a list of all users on the instance. The
          `UsersFinder` class performs an exact match on the `username`, so we are
          guaranteed to get 0 or 1 users.
        - Verify that the resulting user (if any) is accessible to be viewed publicly
          by calling `can?(current_user, :read_user, user)`
  5. 23 Jun, 2017 1 commit
    • Add User#full_private_access? to check if user has Private access · b90f1098
      Toon Claes authored
      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
  6. 21 Jun, 2017 1 commit
  7. 19 Jun, 2017 1 commit
  8. 18 Jun, 2017 1 commit
  9. 16 Jun, 2017 1 commit
    • Refactor ProjectsFinder#init_collection · d2934722
      Yorick Peterse authored
      This changes ProjectsFinder#init_collection so it no longer relies on a
      UNION. For example, to get starred projects of a user we used to run:
      
          SELECT projects.*
          FROM projects
          WHERE projects.pending_delete = 'f'
          AND (
              projects.id IN (
                  SELECT projects.id
                  FROM projects
                  INNER JOIN users_star_projects
                      ON users_star_projects.project_id = projects.id
                  INNER JOIN project_authorizations
                      ON projects.id = project_authorizations.project_id
                  WHERE projects.pending_delete = 'f'
                  AND project_authorizations.user_id = 1
                  AND users_star_projects.user_id = 1
      
                  UNION
      
                  SELECT projects.id
                  FROM projects
                  INNER JOIN users_star_projects
                      ON users_star_projects.project_id = projects.id
                  WHERE projects.visibility_level IN (20, 10)
                  AND users_star_projects.user_id = 1
              )
          )
          ORDER BY projects.id DESC;
      
      With these changes the above query is turned into the following instead:
      
          SELECT projects.*
          FROM projects
          INNER JOIN users_star_projects
              ON users_star_projects.project_id = projects.id
          WHERE projects.pending_delete = 'f'
          AND (
              EXISTS (
                  SELECT 1
                  FROM project_authorizations
                  WHERE project_authorizations.user_id = 1
                  AND (project_id = projects.id)
              )
              OR projects.visibility_level IN (20,10)
          )
          AND users_star_projects.user_id = 1
          ORDER BY projects.id DESC;
      
      This query in turn produces a better execution plan and takes less time,
      though the difference is only a few milliseconds (this however depends
      on the amount of data involved and additional conditions that may be
      added).
  10. 15 Jun, 2017 2 commits
    • Make the GroupFinder specs more strict · aeaf5860
      Toon Claes authored
      Ensure the results match exactly and project authorizations do allow access to
      sibling groups/projects deeper down.
      
      Also apply WHERE scopes before running the UNION, to increase performance.
    • Subgroups page should show groups authorized through inheritance · ef1811f4
      Toon Claes authored
      When a user is authorized to a group, they are also authorized to see all the
      ancestor groups and descendant groups.
      
      When a user is authorized to a project, they are authorized to see all the
      ancestor groups too.
      
      Closes #32135
      
      See merge request !11764
  11. 06 Jun, 2017 1 commit
    • Introduce an Events API · ad3e180e
      Mark Fletcher authored
      * Meld the following disparate endpoints:
       * `/projects/:id/events`
       * `/events`
       * `/users/:id/events`
      + Add result filtering to the above endpoints:
       * action
       * target_type
       * before and after dates
  12. 02 Jun, 2017 1 commit
  13. 30 May, 2017 4 commits
    • Add :owned param to ProjectFinder · db679788
      Toon Claes authored
      And use it in the API.
    • Make it possible to combine :trending with other params · 5654ac87
      Toon Claes authored
      Now it is possible to combine the :non_public parameter. This might be useful
      when a user wants to know the trending projects they are member of.
    • UNION of SELECT/WHERE is faster than WHERE on UNION · 01c6323d
      Toon Claes authored
      Instead of applying WHERE on a UNION, apply the WHERE on each of the seperate
      SELECT statements, and do UNION on that.
      
      Local tests with about 2_000_000 projects:
       - 1_500_000 private projects
       -    40_000 internal projects
       -   400_000 public projects
      
      For the API endpoint `/api/v4/projects?visibility=private` the slowest query was:
      
      ```sql
      SELECT "projects".*
      FROM "projects"
      WHERE ...
      ```
      
      The original query took 1073.8ms.
      The query refactored to UNION of SELECT/WHERE took 2.3ms.
      
      The original query was:
      
      ```sql
      SELECT "projects".*
      FROM "projects"
      WHERE "projects"."pending_delete" = $1
        AND (projects.id IN
               (SELECT "projects"."id"
                FROM "projects"
                INNER JOIN "project_authorizations" ON "projects"."id" = "project_authorizations"."project_id"
                WHERE "projects"."pending_delete" = 'f'
                  AND "project_authorizations"."user_id" = 23
                UNION SELECT "projects"."id"
                FROM "projects"
                WHERE "projects"."visibility_level" IN (20,
                                                        10)))
        AND "projects"."visibility_level" = $2
        AND "projects"."archived" = $3
      ORDER BY "projects"."created_at" DESC
      LIMIT 20
      OFFSET 0 [["pending_delete", "f"],
             ["visibility_level", 0],
             ["archived", "f"]]
      ```
      
      The refactored query:
      ```sql
      SELECT "projects".*
      FROM "projects"
      WHERE "projects"."pending_delete" = $1
        AND (projects.id IN
               (SELECT "projects"."id"
                FROM "projects"
                INNER JOIN "project_authorizations" ON "projects"."id" = "project_authorizations"."project_id"
                WHERE "projects"."pending_delete" = 'f'
                  AND "project_authorizations"."user_id" = 23
                  AND "projects"."visibility_level" = 0
                  AND "projects"."archived" = 'f'
                UNION SELECT "projects"."id"
                FROM "projects"
                WHERE "projects"."visibility_level" IN (20,
                                                        10)
                  AND "projects"."visibility_level" = 0
                  AND "projects"."archived" = 'f'))
      ORDER BY "projects"."created_at" DESC
      LIMIT 20
      OFFSET 0 [["pending_delete", "f"]]
      ```
    • Change ProjectFinder so starred can be combined with other filters · 07250508
      Toon Claes authored
      The `starred` parameter couldn't be used in combination with `trending` or
      `non_public`. But this is changed now.
  14. 15 May, 2017 1 commit
  15. 10 May, 2017 2 commits
  16. 07 May, 2017 1 commit
  17. 04 May, 2017 1 commit
  18. 02 May, 2017 10 commits