BigW Consortium Gitlab

  1. 15 May, 2017 1 commit
  2. 10 May, 2017 2 commits
  3. 08 May, 2017 2 commits
    • Devise can assign trackable fields, but only allow writes once/hour · 3531ea09
      Toon Claes authored
      Not assigning the trackable fields seems to cause strange side-effects.
    • Limit `update_tracked_fields` to write to database once/hour · 6a915d6f
      Toon Claes authored
      Every time a user logs in or out, the Trackable attributes are written to the
      database. This is causing a lot of load on the database, for data that isn't
      really critical.
      
      So to avoid the database being hammered, add a Gitlab::ExclusiveLease before
      writing trackable attributes to the database. This lease expires after an hour,
      so only when the attributes were written more than an hour ago, they can be
      written again. Otherwise they are ignored.
  4. 05 May, 2017 1 commit
  5. 04 May, 2017 2 commits
  6. 01 May, 2017 1 commit
  7. 26 Apr, 2017 1 commit
  8. 19 Apr, 2017 1 commit
  9. 18 Apr, 2017 1 commit
  10. 11 Apr, 2017 1 commit
  11. 09 Apr, 2017 1 commit
  12. 06 Apr, 2017 5 commits
    • Implement review comments from @DouweM for !10467. · 1c42505b
      Timothy Andrew authored
      1. Have `MigrateToGhostUser` be a service rather than a mixed-in module, to keep
         things explicit. Specs testing the behavior of this class are moved into a
         separate service spec file.
      
      2. Add a `user.reported_abuse_reports` association to make the
         `migrate_abuse_reports` method more consistent with the other `migrate_`
         methods.
    • Fix a bug with the User#abuse_report association. · 6a065074
      Timothy Andrew authored
      Introduction
      ------------
      
      1. The foreign key was not explicitly specified on the association.
      2. The `AbuseReport` model contains two references to user - `reporter_id` and
         `user_id`
      3. `user.abuse_report` is supposed to return the single abuse report where
         `user_id` refers to the given user.
      
      Bug Description
      ---------------
      
      1. `user.abuse_report` would return an abuse report where `reporter_id` referred
         to the current user, if such an abuse report was present.
      
      2. This implies a slightly more serious bug as well:
      
         - Assume User A filed an abuse report against User B
         - We have an abuse report where `reporter_id` is User A and `user_id` is User B
         - If User A is updated (`user_a.block`, for example), the abuse report would
           also be updated, such that both `reporter_id` _and_ `user_id` point to User A.
      
      Fix
      ---
      
      Explicitly declare the foreign key `user_id` in the `has_one` declaration
    • check all groups for 2fa requirement · 20575859
      Alexis Reigel authored
    • Support 2FA requirement per-group · a3430f01
      Markus Koller authored
  13. 30 Mar, 2017 1 commit
  14. 27 Mar, 2017 1 commit
  15. 24 Mar, 2017 1 commit
  16. 17 Mar, 2017 1 commit
  17. 13 Mar, 2017 1 commit
  18. 09 Mar, 2017 1 commit
  19. 06 Mar, 2017 1 commit
  20. 05 Mar, 2017 1 commit
  21. 28 Feb, 2017 1 commit
  22. 24 Feb, 2017 4 commits
    • Fix specs for the ghost user feature. · 53aa0437
      Timothy Andrew authored
    • Use a `ghost` boolean to track ghost users. · 8e684809
      Timothy Andrew authored
      Rather than using a separate `ghost` state. This lets us have the benefits of
      both ghost and blocked users (ghost: true, state: blocked) without having to
      rewrite a number of queries to include cases for `state: ghost`.
    • Extract code from `Namespace#clean_path` for ghost user generation. · ca16c373
      Timothy Andrew authored
      1. Create a `Uniquify` class, which generalizes the process of generating unique
         strings, by accepting a function that defines what "uniqueness" means in a
         given context.
      
      2. WIP: Make sure tests for `Namespace` pass, add more if necessary.
      
      3. WIP: Add tests for `Uniquify`
    • Deleting a user shouldn't delete associated issues. · ff19bbd3
      Timothy Andrew authored
      - "Associated" issues are issues the user has created + issues that the
        user is assigned to.
      
      - Issues that a user owns are transferred to a "Ghost User" (just a
        regular user with `state = 'ghost'` that is created when
        `User.ghost` is called).
      
      - Issues that a user is assigned to are moved to the "Unassigned" state.
      
      - Fix a spec failure in `profile_spec` — a spec was asserting that when a user
        is deleted, `User.count` decreases by 1. After this change, deleting a user
        creates (potentially) a ghost user, causing `User.count` not to change. The
        spec has been updated to look for the relevant user in the assertion.
  23. 23 Feb, 2017 5 commits
  24. 15 Feb, 2017 2 commits
  25. 13 Feb, 2017 1 commit