To update a project's dates you need the ProjectDates permission, which is separate from the Project Write permission that is required to update other project details.
This is because changing project dates can have a significant impact on any associated roles and phases, and therefore only users with the ProjectDates permission should be allowed to make those changes.
If the "shiftDates" property is true and you specify a changed project start or end date in this request,
then the project's start and end dates, and the start and end dates for all roles and phases
will be adjusted by the same amount. If this property is set to true, then you must only send
EITHER startDate OR endDate - behavior when setting both is to shift with project start date..
If the "removeRoleSetup" property is true, then all roles are removed from the given project.
If the "expandRole" property is true and you specify a changed project start to be earlier than the
current start date, or you specify a changed project end date to be later than the current
end date, then any roles that share the same date will be expanded so that they
still start or end on the same date that the project starts or ends. The duration of those
roles will be expanded in this case.
For example, take a project running from February 1, 2020 to July 1, 2020, where Role A runs from
February 1, 2020 to March 1, 2020, and Role B runs from February 15, 2020 to July 1, 2020.
If a PATCH request is sent with startDate = January 15, 2020 and expandRole = true, then
the project will be modified to run from January 15, 2020 to July 1, 2020, role A will be modified
to run from January 15, 2020 to March 1, 2020, and role B will remain unmodified. If instead you
specify expandRole = false, then the roles will be unmodified in this situation.
If the "expandPhases" property is true and you specify a changed project start to be earlier than the
current start date, or you specify a changed project end date to be later than the current
end date, then any phases that share the same date will be expanded so that they
still start or end on the same date that the project starts or ends. The duration of those
phases will be expanded in this case.
For example, take a project running from February 1, 2020 to July 1, 2020, where Phase A runs from
February 1, 2020 to March 1, 2020, and Phase B runs from March 2, 2020 to July 1, 2020.
If a PATCH request is sent with startDate = January 15, 2020 and expandPhases = true, then
the project will be modified to run from January 15, 2020 to July 1, 2020, Phase A will be modified
to run from January 15, 2020 to March 1, 2020, and Phase B will remain unmodified. If instead you
specify expandPhase = false, then the phases will be unmodified in this situation.
If you update a project to a "type" of Awarded without specifying a state, it will default to a date based state.
You can specify a state, but if you pass Active, Completed or Upcoming the API will ignore those values and return a date based state.
If you set it to Canceled it will cancel the project and the allocation stats for the account will no longer be affected by the project.
You can re-activate a project by passing Active, Completed or Upcoming and the API will return the proper date based state.
An Awarded project can only have a state of Active, Completed, Upcoming or Canceled.
If you update a project to type of Opportunity without specifying a state, default to a state of Pursuit.
An Opportunity can only have a state of Pursuit or Lost.
The "winPercent" is associated with an Opportunity, you can update the winPercent for an Opportunity in Pursuit state but not for an Awarded project.
NOTE: Opportunities do not count towards allocation statistics so, any roles and allocations set on the project will not cause conflicts, issues, over-allocations etc.
Permissions
Project: Write
ProjectDates: Write
Role: Read
HourlyRole: Read
| Time | Status | User Agent | |
|---|---|---|---|
Retrieving recent requests… | |||
400Bad Request - Request has missing or invalid values
Example when trying to update a project with an invalid colour value:
{
401Unauthorized
403Forbidden - User doesn't have permissions on this resource, or the project couldn't be found.
409Conflict - A project already exists in the account with the same name.
Example when trying to update a project name to the same name as an existing one:
{
422Unprocessable Entity - Updated end or start date is invalid.
Example when trying to update a project end date that would result in the end date being before the current start date:
{