Content
View differences
Updated by Jens Ulferts over 10 years ago
**Acceptance criteria**
- work package table uses the APIv3 as it’s data source (see caveat below). It currently uses the experimental API.
- the functionality the table currently possesses is kept unchanged. The functionality that the table itself posesses is especially (noting it down so that it is not forgotten):
- Summing up columns
- Bulk edit
- …
**Out of scope**
- The rest of the page is left unchanged. That means that the page still uses the experimental API to a huge extend, e.g. to get the query information.
- Due/start date is always displayed as two columns even for work packages of type milestone
**Caveat**
It migth be beneficial to first change the experimental API to be in parts compatible with the APIv3. That would mean to change the work packages listed in
https://community.openproject.org/api/experimental/projects/[project identifier]/work_packages.json
to be rendered with the APIv3’s representer.
**Technical solution**
- The client side data structure for a work package is the same regardless of whether it is displayed in the split screen, the full screen or is part of the wp table
- The data for the wp table comes frome either:
- The experimental API’s work\_packages endpoint which is altered so that the work packages are rendered using the APIv3 work package representer
- The APIv3’s work package endpoint. For that, we still have to send a request to the experimental API to get the current query. That query information is then parsed and subsequently send as part of the query parameters to the APIv3 work package endpoint:
<!-- end list -->
/api/v3/projects/{id}/work_packages{?offset,pageSize,filters,sortBy,groupBy,showSums}
- The actions available for bulk editing can be taken from the links in each work package. That calculation is similar to the currently established one.
**Open:**
- The sums of columns might have to be calculated front end side. The API only returns the total sum. This might be problematic if we ever want to have more complicated arithmetics (e.g. not summing attributes of child work package if their parent is already factored in)
- The performance of the APIv3 work package index action seems to be slower compared to the experimental API (e.g. 4 sec compared to 400ms)
- work package table uses the APIv3 as it’s data source (see caveat below). It currently uses the experimental API.
- the functionality the table currently possesses is kept unchanged. The functionality that the table itself posesses is especially (noting it down so that it is not forgotten):
- Summing up columns
- Bulk edit
- …
**Out of scope**
- The rest of the page is left unchanged. That means that the page still uses the experimental API to a huge extend, e.g. to get the query information.
- Due/start date is always displayed as two columns even for work packages of type milestone
**Caveat**
It migth be beneficial to first change the experimental API to be in parts compatible with the APIv3. That would mean to change the work packages listed in
https://community.openproject.org/api/experimental/projects/[project identifier]/work_packages.json
to be rendered with the APIv3’s representer.
**Technical solution**
- The client side data structure for a work package is the same regardless of whether it is displayed in the split screen, the full screen or is part of the wp table
- The data for the wp table comes frome either:
- The experimental API’s work\_packages endpoint which is altered so that the work packages are rendered using the APIv3 work package representer
- The APIv3’s work package endpoint. For that, we still have to send a request to the experimental API to get the current query. That query information is then parsed and subsequently send as part of the query parameters to the APIv3 work package endpoint:
<!-- end list -->
/api/v3/projects/{id}/work_packages{?offset,pageSize,filters,sortBy,groupBy,showSums}
- The actions available for bulk editing can be taken from the links in each work package. That calculation is similar to the currently established one.
**Open:**
- The sums of columns might have to be calculated front end side. The API only returns the total sum. This might be problematic if we ever want to have more complicated arithmetics (e.g. not summing attributes of child work package if their parent is already factored in)
- The performance of the APIv3 work package index action seems to be slower compared to the experimental API (e.g. 4 sec compared to 400ms)