New Fields Added to Event Specification
New Fields Added to Event Specification
The Event resource specification now includes two new fields:
created_at
specifying when an event was createdrecorded_at
specifying when an event was registered in the database
Updates
- Added new fields
created_at
andrecorded_at
to the [Event] resource specification 2.
Where to get support
Should you have any issues or need further guidance, please post a request to our developer forum for any help needed.
New Editable Shared Links API
New Editable Shared Links API
Now, developers can make files editable via shared links using the API.
Documentation Updates
- Added a new
can_edit
value to thepermissions
object for the file, folder, and web link resources - Added a new
shared_link_permission_options
field to thefile--full
resource - Added a shared link section for web links in the reference documentation
- Added a permissions page to the shared links guide documentation
- Combined the update and add shared link guide page since they utilize the same PUT endpoint
- Updated code snippets across several shared link pages
Enhancement Details
- Instead of having to collaborate a user into a file to give edit access, you can set the
shared_link.permissions.can_edit
field totrue
. - The
can_edit
field will be returned for all shared link objects on files, folders, and web links; however, you can only set it to true for a file. - Our SDK libraries will gain this feature in the coming quarters.
- If an admin has turned off editable shared links in the admin console, you will not be able to use this feature.
cURL Example
curl -i -X PUT 'https://api.box.com/2.0/files/123456789?fields=shared_link' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer [ACCESS TOKEN]' \
-d '{
"shared_link": {
"permissions": {
"can_preview": true,
"can_download": true,
"can_edit": true
}
}
}'
Where to get support
Should you have any issues or need further guidance, please post a request to our developer forum for any help needed.
New Field Added to Sign Events Payload
New Field Added to Sign Events Payload
The additional_details
Sign Events payload now includes the batch_send
field identifying a sign request sent to multiple recipients at once. If such a batch send request exists, the payload also provides its id
.
Updates
- Added new field
batch_send
toadditional_details
payload for Sign Events.
Where to get support
Should you have any issues or need further guidance, please post a request to our developer forum for any help needed.
Improvements In Custom Apps Approval Flow
Improvements In Custom Apps Approval Flow
Today we added further improvements to the custom apps approval flow. As a result, you can now use a new Enablement tab in Developer Console to directly request a Box Admin to enable OAuth 2.0 custom apps.
Additionally, Box Admins can use Custom Apps Manager to view and enable custom apps in Admin Console.
Updates
- Enablement tab was added for OAuth 2.0 custom apps.
- Information on enabling OAuth 2.0 custom applications has been added to the custom app approval guide page.
- Screenshots have been updated on the custom app approval and setup with OAuth 2.0 guide pages.
Where to get support
Should you have any issues or need further guidance, please post a request to our developer forum for any help needed.
Box Windows SDK v4.3.1
released
Notice of behavior change for collaboration events on the changes stream
Notice of behavior change for collaboration events on the changes stream
Starting today, we will begin rolling out changes to the behavior of collaboration events when an application consumes those events from our event API endpoints.
This change will only affect COLLAB_INVITE_COLLABORATOR
,
COLLAB_ADD_COLLABORATOR
, COLLAB_ROLE_CHANGE
, and
COLLAB_REMOVE_COLLABORATOR
user events
with the query parameter stream_type
set to changes
.
This will not affect existing enterprise events.
The new behavior will not cause downtime within existing applications
or require any application changes to prevent uptime disruptions.
Change overview
Previously, events of type COLLAB_INVITE_COLLABORATOR
,
COLLAB_ADD_COLLABORATOR
, COLLAB_ROLE_CHANGE
, and
COLLAB_REMOVE_COLLABORATOR
created notifications
for the acted upon users that were listening to the changes
stream.
Owners of the collaborated item would not receive these events unless
they were listening to the all
stream as well.
We are cleaning up this discrepancy by establishing parity
between the all
and changes
stream. With this new behavior,
notifications of a collaboration will be created for the content owner
on the changes
stream as well. Collaboration owners will now see an
additional event that matches what they see on the all
stream.
Where to get support
Should you have any issues or need further guidance, please post a request to our developer forum for any help needed.