Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
  • 12-9-stable
  • 12-7-stable
  • 12-6-stable
  • 12-8-stable
  • github/fork/Kloppi313/patch-1
  • 12-5-stable
  • 12-4-stable
  • github/fork/ramalokesh8477/master
  • 12-1-stable
  • 12-2-stable
  • 12-0-stable
  • 12-3-stable
  • 42-42-stable
  • github/fork/hussamgit398/patch-2
  • 12-3-auto-deploy-20190911
  • 12-3-auto-deploy-20190916
  • 12-3-auto-deploy-20190908
  • 12-3-auto-deploy-20190901
  • 12-3-auto-deploy-20190901-32664
  • v12.10.0.pre
  • v12.9.0
  • v12.9.0-rc42
  • v12.8.7
  • v12.8.6
  • v12.8.5
  • v12.8.4
  • v12.8.3
  • v12.6.8
  • v12.7.7
  • v12.8.2
  • v12.8.1
  • v12.9.0.pre
  • v12.8.0
  • v12.8.0-rc42
  • v12.5.10
  • v12.7.6
  • v12.6.7
  • v12.7.5
  • v12.5.9
40 results

api_update_service.rb

  • Timothy Andrew's avatar
    f79f3a1d
    Fix branch protection API. · f79f3a1d
    Timothy Andrew authored
    1. Previously, we were not removing existing access levels before
       creating new ones. This is not a problem for EE, but _is_ for CE,
       since we restrict the number of access levels in CE to 1.
    
    2. The correct approach is:
    
        CE -> delete all access levels before updating a protected branch
        EE -> delete developer access levels if "developers_can_{merge,push}" is switched off
    
    3. The dispatch is performed by checking if a "length: 1" validation is
       present on the access levels or not.
    
    4. Another source of problems was that we didn't put multiple queries in
       a transaction. If the `destroy_all` passes, but the `update` fails,
       we should have a rollback.
    
    5. Modifying the API to provide users direct access to CRUD access
       levels will make things a lot simpler.
    
    6. Create `create/update` services separately for this API, which
       perform the necessary data translation, before calling the regular
       `create/update` services. The translation code was getting too large
       for the API endpoint itself, so this move makes sense.
    f79f3a1d
    History
    Fix branch protection API.
    Timothy Andrew authored
    1. Previously, we were not removing existing access levels before
       creating new ones. This is not a problem for EE, but _is_ for CE,
       since we restrict the number of access levels in CE to 1.
    
    2. The correct approach is:
    
        CE -> delete all access levels before updating a protected branch
        EE -> delete developer access levels if "developers_can_{merge,push}" is switched off
    
    3. The dispatch is performed by checking if a "length: 1" validation is
       present on the access levels or not.
    
    4. Another source of problems was that we didn't put multiple queries in
       a transaction. If the `destroy_all` passes, but the `update` fails,
       we should have a rollback.
    
    5. Modifying the API to provide users direct access to CRUD access
       levels will make things a lot simpler.
    
    6. Create `create/update` services separately for this API, which
       perform the necessary data translation, before calling the regular
       `create/update` services. The translation code was getting too large
       for the API endpoint itself, so this move makes sense.