Content
View differences
Updated by Bruno Pagno 6 days ago
Goal:
* Include `target_versions` on work package API
* On READ operation, return the value from work\_package.version encapsulated on an array
* On WRITE operation, validate that a single value has been passed (as in, an array of a single value), and then do the same operation that WRITE version does.
* Mark `versions` field on work package API as deprecated
* Exclude target\_versions from any UI (e.g. form configuration, work package list/details views)
* Investigate and implement a way of communicating that we're replacing the single version field for target\_versions on the API
<br>
Additional context:
In the context of this ticket, we discuss four operations represented in the WorkPackage API:
1. READ version
2. WRITE version
3. READ target\_versions
4. WRITE target\_versions
<br>
### Decisions:
* We want to avoid breaking changes before the switch
* Before the switch we mark READ/WRITE version as deprecated
* We will need to explain that we're migrating to target versions and how to use them
* After the switch we **remove** READ/WRITE version
* Before the switch READ target\_versions will simply return `[version]`
* The API doesn't allow both writing version & target\_version in the same request
* We filter out the new fields from the UI at this time
<br>
### Open Questions:
* How can we WRITE target\_versions **before** the switch?
* Validate single value
* How can we WRITE version **after** the switch?
* We don't
* Include `target_versions` on work package API
* On READ operation, return the value from work\_package.version encapsulated on an array
* On WRITE operation, validate that a single value has been passed (as in, an array of a single value), and then do the same operation that WRITE version does.
* Mark `versions` field on work package API as deprecated
* Exclude target\_versions from any UI (e.g. form configuration, work package list/details views)
* Investigate and implement a way of communicating that we're replacing the single version field for target\_versions on the API
<br>
Additional context:
In the context of this ticket, we discuss four operations represented in the WorkPackage API:
1. READ version
2. WRITE version
3. READ target\_versions
4. WRITE target\_versions
<br>
### Decisions:
* We want to avoid breaking changes before the switch
* Before the switch we mark READ/WRITE version as deprecated
* We will need to explain that we're migrating to target versions and how to use them
* After the switch we **remove** READ/WRITE version
* Before the switch READ target\_versions will simply return `[version]`
* The API doesn't allow both writing version & target\_version in the same request
* We filter out the new fields from the UI at this time
<br>
### Open Questions:
* How can we WRITE target\_versions **before** the switch?
* Validate single value
* How can we WRITE version **after** the switch?
* We don't