Bridgit RoleAllocations API

openapi: 3.0.4
info:
  title: Bench AccountActivities RoleAllocations API
  description: "<h2>Versioning</h2>\n<p>\n    The API is currently at version <code>1.0</code>. All API endpoints (other than\n    authentication) require you to specify the API version as part of the path.\n</p>\n\n<h2>URL Paths</h2>\n<p>\n    Authentication requests should be made to <code>/auth/signin</code>,\n    as documented below. All other API requests should be made to\n    sub-paths of <code>/rp/api/1.0/...</code>.\n</p>\n\n<h2>Authentication</h2>\n<p>\n    API requests are authenticated using an OAuth Bearer token.\n    You can get a token by authenticating your user by sending a\n    POST request to <code>/auth/signin</code>, with \"username and \"password\"\n    parameters form-encoded in the body of the request.\n\n    POST /auth/signin HTTP/1.1\n    Content-Type: application/x-www-form-urlencoded\n\n    username=user@example.com&password=some-secret-password\n</p>\n<p>\n    The response will be a JSON object including both\n    <b>\"access_token\"</b> and <b>\"refresh_token\"</b> property.\n    All other requests against the Bench API should include an\n    authorization header: <code>Authorization: Bearer xxxYYYzzz</code>,\n    where <b>xxxYYYzzz</b> is the value of <b>\"access_token\"</b> in the response.\n    <br><br>\n    For example:\n\n    $ curl https://bench.gobridgit.com/auth/signin -H 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'username=someone@example.com' --data-urlencode 'password=[...snip...]'\n    {\n        \"access_token\": \"...snip...\",\n        \"token_type\": \"Bearer\",\n        \"refresh_token\": \"...snip...\"\n        \"expiry\": \"2020-01-01T00:00:00.413440849Z\"\n    }\n\n</p>\n\n<p>\n    The refresh token can be used to generate new session by request with <code>/auth/token</code> endpoint:\n\n    POST /auth/token HTTP/1.1\n    Content-Type: application/x-www-form-urlencoded\n\n    grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA\n</p>\n<p>\n    Note that once the refresh token is used, the previous access and refresh token is no longer valid.\n    <br><br>\n    For example:\n\n    $ curl https://bench.gobridgit.com/auth/token -H 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'grant_type=refresh_token' --data-urlencode 'refresh_token=[...snip...]'\n    {\n        \"access_token\": \"...snip...\",\n        \"token_type\": \"Bearer\",\n        \"refresh_token\": \"...snip...\"\n        \"expiry\": \"2020-01-01T00:00:00.413440849Z\"\n    }\n</p>\n\n<h2>Pagination</h2>\n<p>\n    Several of the API endpoints are paginated. These are denoted by\n    including the <code>offset</code> (zero-based offset) and <code>limit</code> query\n    parameters. For example, to request the <code>10</code> items,\n    set the <code>offset=0</code> to <code>limit=10</code>.\n    <br>\n    NOTE: the result set contains items with index of 0-9\n    <br>\n    To request the next 10 items (starting at index 10),\n    set the <code>offset=10</code> to <code>limit=10</code>\n</p>\n<p>\n    Responses to paginated API endpoints return a JSON array of objects.\n    If there are results beyond the page you have requested, the server\n    will set a <code>query-has-more: true</code> header in the response.\n</p>\n\n<h2>Request Encoding</h2>\n<p>\n    <code>GET</code> and <code>DELETE</code> requests should have parameters encoded as URL query\n    parameters. Boolean values should be encoded as <code>true</code> and\n    <code>false</code>, not as <code>1</code> and <code>0</code>.\n</p>\n\n<h2>Errors</h2>\n<p>\n    Errors are returned for some response codes such as <code>400 Bad Request</code> in the\n    following format:\n\n    {\n      \"errors\": [\n        {\n          \"errorType\": \"ValidationError\",\n          \"description\": \"The value of Name must be a string with a minimum length of 1 and a maximum length of 8 and not whitespace.\",\n          \"field\": \"Name\",\n          \"values\": [\n            null\n          ]\n        }\n      ],\n      \"title\": \"One or more validation errors occurred.\",\n      \"status\": 400,\n      \"instance\": \"api/v1/accounts/0/persons\",\n      \"requestUid\": \"123e4567-e89b-12d3-a456-426614174000\"\n    }\n</p>\n"
  version: '1.0'
servers:
- url: https://bench.gobridgit.com
  description: Bridgit Bench production
security:
- {}
tags:
- name: RoleAllocations
paths:
  /rp/api/v1/accounts/{accountId}/projects/{projectId}/roles/{roleId}/allocations:
    post:
      tags:
      - RoleAllocations
      summary: Allocates a person to a role on the given account and project
      description: 'A person cannot be allocated entirely inside a period of unavailability and cannot be allocated outside of their employment dates.


        For allocations that overlap a period of unavailability, the API will truncate or not set the date range that the person is unavailable.


        Examples: Unavaialble from 2020-01-11 to 2020-01-25, Allocation date from 2020-01-20 to 2020-03-31, will alocate the person from 2020-01-26 to 2020-03-31


        Unavaialble from 2020-01-11 to 2020-01-25, Allocation date from 2020-01-01 to 2020-03-31, will alocate the person from 2020-01-01 to 2020-01-10 AND 2020-01-26 to 2020-03-31<br/><strong>Permissions</strong><br/>Person: Read<br/>Role: Read<br/>Allocation: Write<br/>Private: Read'
      operationId: RoleAllocations_Post
      parameters:
      - name: accountId
        in: path
        description: The Account ID
        required: true
        schema:
          type: integer
          format: int32
      - name: projectId
        in: path
        description: The Project ID
        required: true
        schema:
          type: integer
          format: int64
      - name: roleId
        in: path
        description: The Role ID
        required: true
        schema:
          type: integer
          format: int64
      requestBody:
        description: Request object containing the person, role, start and end date to allocate
        content:
          application/json-patch+json:
            schema:
              $ref: '#/components/schemas/ProjectRoleAllocationRequest'
          application/json:
            schema:
              $ref: '#/components/schemas/ProjectRoleAllocationRequest'
          text/json:
            schema:
              $ref: '#/components/schemas/ProjectRoleAllocationRequest'
          application/*+json:
            schema:
              $ref: '#/components/schemas/ProjectRoleAllocationRequest'
        required: true
      responses:
        '200':
          description: OK
        '400':
          description: Bad Request
        '401':
          description: Unauthorized
        '403':
          description: Forbidden
        '409':
          description: Conflict
        '422':
          description: Unprocessable Entity
components:
  schemas:
    ProjectRoleAllocationRequest:
      type: object
      properties:
        personId:
          type: integer
          format: int64
          example: 1
        startDate:
          type: string
          format: date-time
          example: '2019-01-01'
        endDate:
          type: string
          format: date-time
          example: '2019-12-31'
      additionalProperties: false
  securitySchemes:
    Bearer:
      type: http
      description: Standard Authorization header using the Bearer scheme
      scheme: bearer
      bearerFormat: JWT