Skip to content
Snippets Groups Projects
  1. Jul 19, 2019
  2. Jul 04, 2019
  3. Jun 27, 2019
    • Thong Kuah's avatar
      Remove group_clusters feature flag · 3f759e16
      Thong Kuah authored
      Now we have terminals for instance and group clusters we can remove the
      FF now. Deploying to group clusters has been working without complaints
      too.
      3f759e16
  4. Jun 13, 2019
  5. May 31, 2019
  6. Apr 23, 2019
  7. Apr 05, 2019
    • mksionek's avatar
      Add part of needed code · 64858317
      mksionek authored
      Add columns to store project creation settings
      
      Add project creation level column in groups
       and default project creation column in application settings
      
      Remove obsolete line from schema
      
      Update migration with project_creation_level column existence check
      
      Rename migrations to avoid conflicts
      
      Update migration methods
      
      Update migration method
      64858317
  8. Apr 04, 2019
    • mksionek's avatar
      Add cr remarks · 17bee986
      mksionek authored and James Lopez's avatar James Lopez committed
      Chnage method used in model to make it
      more efficient database-wise
      Add additional spec
      17bee986
  9. Mar 18, 2019
  10. Mar 06, 2019
  11. Jan 24, 2019
  12. Jan 16, 2019
    • Alejandro Rodríguez's avatar
      Return max group access level in the projects API · ab94a5a5
      Alejandro Rodríguez authored
      Currently if a project is inside a nested group and a user doesn't have
      specific permissions for that group but does have permissions on a
      parent group the `GET /projects/:id` API call will return the following
      permissions:
      
      ```json
      permissions: { project_access: null, group_access: null }
      ```
      
      It could also happen that the group specific permissions are of lower
      level than the ones the user has in parent groups. This patch makes it
      so that the permission returned for `group_access` is the highest from
      amongst the hierarchy, which is (ostensibly) the information that the
      API user is interested in for that field.
      ab94a5a5
  13. Dec 19, 2018
  14. Dec 04, 2018
    • Thong Kuah's avatar
      Unify into :group_clusters feature flag · ebf87fd9
      Thong Kuah authored
      With this MR, group clusters is now functional, so default to enabled.
      
      Have a single setting on the root ancestor group to enabled or disable
      group clusters feature as a whole
      ebf87fd9
  15. Dec 03, 2018
  16. Nov 16, 2018
  17. Oct 30, 2018
  18. Oct 29, 2018
    • Thong Kuah's avatar
      Associate clusters model to groups · 0e15eec8
      Thong Kuah authored
      Even though we currently only should have one group for a cluster, we
      allow the flexibility to associate to other groups in the future.
      
      This also matches the runner <=> groups association.
      
      - Adds Cluster#first_group, aliased to Cluster#group. For the
      conceivable future, a cluster will have at most one group.
      
      - Prevent mixing of group and project clusters. If project type
      clusters, it should only have projects assigned.  Similarly with groups.
      
      - Default cluster_type to :project_type. As it's very small table we can
      set default and null: false in one release.
      0e15eec8
  19. Sep 24, 2018
  20. Sep 17, 2018
    • Yorick Peterse's avatar
      Added FromUnion to easily select from a UNION · 8a72f5c4
      Yorick Peterse authored
      This commit adds the module `FromUnion`, which provides the class method
      `from_union`. This simplifies the process of selecting data from the
      result of a UNION, and reduces the likelihood of making mistakes. As a
      result, instead of this:
      
          union = Gitlab::SQL::Union.new([foo, bar])
      
          Foo.from("(#{union.to_sql}) #{Foo.table_name}")
      
      We can now write this instead:
      
          Foo.from_union([foo, bar])
      
      This commit also includes some changes to make this new setup work
      properly. For example, a bug in Rails 4
      (https://github.com/rails/rails/issues/24193) would break the use of
      `from("sub-query-here").includes(:relation)` in certain cases. There was
      also a CI query which appeared to repeat a lot of conditions from an
      outer query on an inner query, which isn't necessary.
      
      Finally, we include a RuboCop cop to ensure developers use this new
      module, instead of using Gitlab::SQL::Union directly.
      
      Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/51307
      Verified
      8a72f5c4
  21. Sep 11, 2018
  22. Aug 06, 2018
  23. Aug 02, 2018
  24. Jul 26, 2018
Loading