From fda62c4beecde1425d5b529acc1a812d3f969beb Mon Sep 17 00:00:00 2001 From: Nathaniel Kam <158605306+pcg-nathaniel@users.noreply.github.com> Date: Tue, 30 Apr 2024 10:26:03 -0400 Subject: [PATCH 1/2] Custom time_frame must be JSON body NOT parameter key value No where does it say time_frame is a post body object rather than key pair, this actually will NOT run as url parameter. Please take note this is poor consistency as filter DOES accept JSON via key-value param, so there is an expectation time_frame (also technically a filter, should too). Response received when running as parameter { "message": "{\n \"time_frame\": {\n \"from\": \"2020-01-01\",\n \"to\": \"2024-12-31\"\n }\n} is not a valid time_frame" } --- source/includes/_reports.md | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/source/includes/_reports.md b/source/includes/_reports.md index 7b8fc4f..47c291a 100644 --- a/source/includes/_reports.md +++ b/source/includes/_reports.md @@ -14,7 +14,7 @@ With the exception of `today` and `calc_incurred_using`, each of the following p | param | data type | description | default | | ----- | --------- | ----------- | ------- | | [`view`](#view) | string | the name of the view (e.g. `time_fees_hours`, `utilization`, etc.) | `"time_fees_hours"` | -| [`time_frame`](#time_frame) | object or string | a custom time frame object or the name of the time frame | `"this_week"` | +| [`time_frame`](#time_frame) | object or string | a custom time frame object as JSON body, example in link OR the name of the time frame as Key-Value Parameter | `"this_week"` | | [`group_by`](#group_by) | array of strings | the attributes to group rows by | `["project_id"]` (or `["user_id"]` for utilization) | | [`filters`](#filters) | object of objects | the attributes and values to include or exclude | `null` | | [`today`](#today) | string | the date on which "future scheduled" begins, in `YYYY-MM-DD` format | current UTC date | @@ -100,16 +100,24 @@ There are currently ten supported views, which correspond to the reports availab ## `time_frame` -The time frame of a report is specified as an object with "from" and "to" attributes that each specify a date in the format YYYY-MM-DD. +There are two options for time_frame + +1) as custom JSON post body object "from" and "to" attributes that each specify a date in the format YYYY-MM-DD + +When submitting a custom time frame, REMOVE the time_frame parameter from your URL and add the following JSON to your post body JSON (this WILL NOT work as a parameter): ```js -"time_frame": { - "from": "2018-01-01", - "to": "2018-12-31" +{ + "time_frame": { + "from": "2020-01-01", + "to": "2024-12-31" + } } ``` -There are also several shortcut strings for common time frames. +2) a URL parameter with a shortcut string. + +When submitting a shortcut string for time_frame, use the URL parameter Key=time_frame and value = one of the options below: - `this_week` - `this_month` From 38474708e5bec801d506345abff6b59dd8b538ab Mon Sep 17 00:00:00 2001 From: Nathaniel Kam <158605306+pcg-nathaniel@users.noreply.github.com> Date: Wed, 12 Jun 2024 11:34:48 -0400 Subject: [PATCH 2/2] Update _custom-fields.md Get Custom fields documentation disregarded the required namespace parameter Updating a namespaces custom field on a record does was ambiguous with the field . --- source/includes/_custom-fields.md | 29 ++++++++++++++++++----------- 1 file changed, 18 insertions(+), 11 deletions(-) diff --git a/source/includes/_custom-fields.md b/source/includes/_custom-fields.md index a31679a..33ec739 100644 --- a/source/includes/_custom-fields.md +++ b/source/includes/_custom-fields.md @@ -84,6 +84,11 @@ PUT /api/v1/custom_fields/ GET /api/v1/custom_fields GET /api/v1/custom_fields/ ``` +##### Required parameters: + +| **Parameter** | **Type** | **Description** | +| ------------- | -------- | --------------- | +| `namespace` | string | either `assignables` or `users` | ### Deleting Custom Fields ``` @@ -124,17 +129,6 @@ POST /api/v1/users//custom_field_values **Note**: Only custom fields with a `data_type` of `multiple_choice_selection_list` can accept an array with multiple values as its `value` in a `POST` request. Note that this array is treated as the complete set of values for the given custom field and project/user. Subsequent `POST` requests for the same custom field and project/user will result in the deletion of previous values if those values are not also included in the `value` array. In other words, subsequent `POST` requests do not _append_ new values, but rather _replace_ the _set_ of values as a whole. -### Updating Custom Field Values -``` -PUT /api/v1/projects//custom_field_values/ -PUT /api/v1/users//custom_field_values/ -``` -##### Editable parameters: - -| **Parameter** | **Type** | **Description** | -| ------------- | -------- | --------------- | -| `value` | string | the actual value | - ### Getting Custom Field Values ``` GET /api/v1/projects//custom_field_values @@ -145,6 +139,19 @@ In addition to getting custom field values directly, you can also include custom GET /api/v1/projects/?fields=custom_field_values GET /api/v1/users/?fields=custom_field_values ``` +### Updating Custom Field Values +``` +PUT /api/v1/projects//custom_field_values/ +PUT /api/v1/users//custom_field_values/ +``` + +**Note**: here is the ID of the custom field ON THE PROJECT or USER, NOT THE GLOBAL ID of the custom field on your account. To get the project or user custom field id use Getting Custom Fields API above. + +##### Editable parameters: + +| **Parameter** | **Type** | **Description** | +| ------------- | -------- | --------------- | +| `value` | string | the actual value | ### Deleting Custom Field Values