**Source URL:** https://general.veevavault.dev/rn/18r1.md

# Vault Developer Release Notes

We are pleased to bring you the following additions and enhancements to Developer Portal features in 18R1.

## Developer Features in 18R1 {#developer-features-in-18r1}

We are pleased to bring you the following additions and enhancements to Developer Portal features in 18R1. REST API features added in 18R1 only affect API v18.1, unless otherwise noted. You can learn more about the [18R1 Release in Vault Help](https://platform.veevavault.help/en/lr/46406).

* [18R1 Fixed Issues](https://platform.veevavault.help/en/lr/47520): View the "Developer Features" category of the Fixed Issues list for Developer Feature fixes in this release. Note that API issues are fixed in API v18.1 only unless otherwise noted.

* [18R1 Known Issues](https://platform.veevavault.help/en/lr/47517): View the "Developer Features" category of the Known Issues list for known issues with Developer Features which are not yet fixed.

<ReleaseNote id="18r1-removal-of-weaker-tls-ciphers" app_family="platform" version="18r1">### Removal of Weaker TLS Ciphers {#18r1-removal-of-weaker-tls-ciphers}

Beginning in 18R1.3 (June 1, 2018), we will remove support for 1024 bit Diffie-Hellman ciphers and TLS v1.0 and will only support Elliptic Curve and TLS v1.2. To ensure your integrations continue working with Vault API, you must ensure that the technology you use to build and run integrations support strong ciphers.

</ReleaseNote>

### Developer Release Notes on the Developer Portal {#18r1-developer-release-notes-on-the-developer-portal}

As of 18R1, we are now publishing the Developer Release notes here on the Developer Portal instead of on Vault Help. Past release information is still available on Vault Help, and can be accessed through the [Past Releases](/rn/previous_versions/) page.

### REST API v18.1 {#18r1-rest-api-v181}

<ReleaseNote id="18r1-user-person-object" lr="17r3.5" app_family="platform" version="18r1">### User & Person Object {#18r1-user-person-object}

In this release, Vault users are now represented as objects. The *User* (`user__sys`) object contains records of all existing Vault users, enabling customers to report on user data, create custom fields, and reference users from documents or objects with lookup fields and reference constraints. The *Person* (`person__sys`) object allows both Vault users and non-users to be in a single object. When referencing a user from a *Person* record, Vault synchronizes the standard fields from both records.

API users can leverage existing Vault object API endpoints to add existing domain users to a Vault, create new users, and add or update users in bulk. API users can also update *Person* records. Note that when API users create, add, or update *User* object records, Vault also synchronizes those changes with the domain user across all Vaults to which that user is a member. This includes cross-domain Vaults.

</ReleaseNote>
<ReleaseNote id="18r1-updates-to-object-record-responses" app_family="platform" version="18r1">### Updates to Object Record Responses {#18r1-updates-to-object-record-responses}

References to users have always appeared as object references with a number as an `id` value in the response. References to objects, such as `product__v`, appear as a String type for the `id`. In v18.1, references to `user__sys` are returned as a String type. In all versions prior to V18.1, references to users and new references to `user__sys` will continue to appear as numbers.

</ReleaseNote>
<ReleaseNote id="18r1-updates-object-metadata-responses" app_family="platform" version="18r1">### Updates Object Metadata Responses {#18r1-updates-object-metadata-responses}

Starting in v18.1, references to `user__sys` will return `user_sys` as the object name with relationship information. Any fields referencing users (not `user__sys`) will continue to return the the name `users` as the object name.

In versions prior to v18.1, references to `user__sys` will return with `users` as when retrieving metadata on any object with a user reference.

</ReleaseNote>
<ReleaseNote id="18r1-controlled-document-templates" lr="17r3.4" app_family="platform" version="18r1">### Controlled Document Templates {#18r1-controlled-document-templates}

In API v18.1, users can create and manage Controlled Document Templates using existing API endpoints. Controlled Document Templates are not supported in previous API versions.

The existing **Bulk Create Document Templates** endpoint can create Controlled Document Templates.

* <span class="label label-warning">POST</span> `/api/{version}/objects/documents/templates`

The existing **Bulk Update Document Templates** endpoint can update Controlled Document Templates, or convert existing basic templates to Controlled Document Templates.

* <span class="label label-info">PUT</span> `/api/{version}/objects/documents/templates`

Direct deletion of Controlled Document Templates via API is not supported. Users can indirectly delete a Controlled Document Template by deleting the document or version referenced by the template.

</ReleaseNote>
<ReleaseNote id="18r1-expose-api-usage-logs" lr="17r3.4" app_family="platform" version="18r1">### Expose API Usage Logs {#18r1-expose-api-usage-logs}

Admin users can now access daily API usage logs. Users with the new **Admin > Logs > API Usage** permission can access these logs via the UI and API.

* <span class="label label-success">GET</span> `/api/{version}/logs/api_usage?date=YYYY-MM-DD`

The required `date` query parameter allows you to get the log from a specific day within the last 30 days. The file is available as a CSV by default, but you can also request a logfile with `log_format=logfile`.

View this endpoint in the [REST API v18.1 Reference](/vault-api/api-reference/18.1/logs/download-daily-api-usage).

</ReleaseNote>
<ReleaseNote id="18r1-enhanced-reports-tab" lr="17r3.4" app_family="platform" version="18r1">### Enhanced Reports Tab {#18r1-enhanced-reports-tab}

With the migration of reports to objects, API users can now read all visible report fields on the `report_sys` object. Hidden fields that contain a report’s filters and related queries are not included.

</ReleaseNote>
<ReleaseNote id="18r1-new-query-parameters-for-domain-endpoint" lr="17r3.4" app_family="platform" version="18r1">### New Query Parameters for Domain endpoint {#18r1-new-query-parameters-for-domain-endpoint}

As of API v18.1, Domain Information API response will omit the `vault_application__v` field from each of Vault JSON objects by default. This will greatly improve the response time of this API. If you want this data, you can set the new query parameter `include_application` to `true`.

View this endpoint in the [REST API v18.1 Reference](/vault-api/api-reference/18.1/domain-information).

</ReleaseNote>
<ReleaseNote id="18r1-user-api-exclude-query-parameters" lr="17r3.3" app_family="platform" version="18r1">### User API exclude query parameters {#18r1-user-api-exclude-query-parameters}

In v17.3, we added two new query parameters to the /users endpoints:

* `exclude_vault_membership`

* `exclude_app_licensing`

These parameters are false by default in v17.3 and below, and `true` by default in v18.1 and above. This means the following endpoints will now exclude `vault_membership` and `app_licensing` information by default:

* <span class="label label-success">GET</span> `/objects/users/me`

* <span class="label label-success">GET</span> `/objects/users/{id}`

* <span class="label label-success">GET</span> `/objects/users`

View these endpoints in the [REST API v18.1 Reference](/vault-api/api-reference/18.1/users).

</ReleaseNote>
<ReleaseNote id="18r1-rendition-types-on-subtype-classification" lr="17r3.3" app_family="platform" version="18r1">### Rendition Types on Subtype & Classification {#18r1-rendition-types-on-subtype-classification}

Since the [Control for Rendition Types on Subtype & Classification](https://platform.veevavault.help/en/lr/30087#control_for_rendition_types_on_subtype_classification) feature, Admins can set renditions at the subtype and classification level. The [Retrieve Document Subtype](/vault-api/api-reference/18.1/documents/retrieve-document-types/retrieve-document-subtype) and [Retrieve Document Classification](/vault-api/api-reference/18.1/documents/retrieve-document-types/retrieve-document-classification) APIs now return this rendition information in v18.1.

</ReleaseNote>

### VQL {#18r1-vql}

<ReleaseNote id="18r1-formula-fields" lr="17r3.4" app_family="platform" version="18r1">### Formula Fields {#18r1-formula-fields}

In 17R3.4, we introduced Formula Fields. Formulas are evaluated during runtime, which means the fields are not stored and are not searchable. They cannot be used with VQL FIND, ORDER BY, WHERE clauses. If there is an error calculating a formula, VQL will return `null` for the field value.

</ReleaseNote>
<ReleaseNote id="18r1-user-object-references" lr="17r3.5" app_family="platform" version="18r1">### User Object References {#18r1-user-object-references}

When including new references to `user__sys` in VQL queries, you must use API v18.1 or later.

</ReleaseNote>

### Known Issues {#known-issues}

#### Configuration Migration {#configuration-migration}

*Issue affected 17R3.4, February 9, 2018. Issue fixed in 17R3.5, March 2, 2018*
The **Import Package** and **Retrieve Package Deploy Results** responses changed in all versions of the API. If you currently have an integration with either of these endpoints where you rely on the structure of the response, your integration may break. In 17R3.5 (March 2, 2018), this change will only affect v18.1 and all other versions will return to normal.
<span class="label label-info">PUT</span> `/api/{version}/services/package`
<span class="label label-success">GET</span> `/api/{version}/vobject/vault_package__v/{package_id}/actions/deploy/results`
To fix your integration, you need to view the new structure of the response and adjust your integration accordingly. When we fix this issue in 17R3.5, you can either return to your old integration code or upgrade your version to v18.1.