Changelog

  • Support of OAuth 2.0 Client Credentials Grant (2024-06-20)

    We now support the option to use client credentials grant during authentication. For further information please have a look at https://docs.timetac.com/#authentification.

  • New version of our API - v4

    In API v4, significant changes were implemented in the schema of specific endpoints related to Tasks, Projects, favouriteTasks, todoTasks, and NodesToUsers.

    New Endpoints:

    • todoTasks (CREATE, READ, DELETE)
    • recentTasks (READ)
    • It maintains queue of last 10 tasks started per user

    Deprecated Endpoint:


    Changes regarding existing endpoints:

     Tasks:

    • Removed columns: 
    • Is_hidden
    • Restrict_tracking_from_to
    • Is_blocked
    •  status = 3 represents it
    • Last_started
    • Utilise the recentTasks/read endpoint instead
    • Is_todo
    •  utilise the todoTasks/ endpoint instead.
    • Is_favourite
    • utilise the 'favouriteTasks/ endpoint instead.


    • New Columns:
    • custom_icon_name
    • target_duration_sum_up_by_task
    • color
    • has_children
    • translate_task_name
    • allow_task_project_edit
    • allow_task_project_delete
    • status
    • external_id
    • Is_restricted


    Projects:

    • Removed (or readonly) columns:
    • Is_hidden
    • Is_blocked
    •  In v4 it will be represented by status = 3
    • Restrict_tracking_from_to
    • Last_started
    • Is_done
    • now marked as readonly. Employ the 'status' field instead, follow the description provided below.
    • New Columns:
    • custom_icon_name
    • target_duration_sum_up_by_task
    • color
    • has_children
    • translate_task_name
    • allow_task_project_edit
    • allow_task_project_delete
    • status
    • External_id


    Description and Possible Values of Field “status”

    • Values:
    • 1: Planning
    • 2: Active
    • 3: Inactive
    • 4: Closed
    • If a status is not specified during CREATE, it inherits the value from its parent.
    • If 'status = 4', then 'is_done' is automatically set to 1; otherwise, it is set to 0.


    Permissions handling

    In API V4, a new endpoint, permissionsProjectsAndTasksPermissions, was introduced to handle all permission-related actions for restricted (is_restricted) projects and tasks. 

    This means that you send the desired state to the API. An example request using the new endpoint to permissionsProjectsAndTasksPermissions/set endpoint is provided below:

    Example Request (JSON):


    [

        {

            "task_project_id": 220, // ID of resource (task/project)

            "resource_id": 19, // 19 = Task, 15 = Project

            "permission_id": 1, // get from endpoint permissions/read/

            "permission_scope_id": 6, 

            "permission_scope_data_1": [10, 14] // IDS of users with access to task with ID 220

        },

        {

            "task_project_id": 220,

            "resource_id": 1, // 19 = Task, 15 = Project

            "permission_id": 1, // get from endpoint permissions/read/

            "permission_scope_id": 6,

            "permission_scope_data_1": [] // all permissions are removed

        }

    ];


    The main difference between SET and CREATE actions on the endpoint:

    permissionsProjectsAndTasksPermissions is that data sent to SET represents the state of permissions. In SET, everything else (for that task or project) will be removed, and only the sent data will be persisted. If the CREATE action is called, nothing is deleted; only new permissions are added.


  • Change logs (2023-09-20)

    We added a change log section 🎉

    You will be able to see what changed from one version to another, see breaking changes and read about new endpoints.