- Reports: we understand that it is not good API practice to have endpoints that are not based on models, but on calculations / manipulations of data. However, they come for free with our reports refactoring and are really useful, so we think we should do them.
Management of funded features
- Customers endpoint [Wishlist #167] -
@jibees to complete implementation, building on @Matt-Yorkley’s PRs. In setting up for implementation, product should create issue labels that match clockify project labels, and we need to get code reviewers to clock their time against this specific project. That way we can track the global time being used to get the funded feature in, even though FR is contributing time.
@lin_d_hop creating the issues to get Customers Endpoint in dev, and will put the Epic in dev ready, for @jibees to pick up
@lin_d_hop to take over the ‘Funded Projects’ tab in Global Product Budget sheet and make it work better, including separate amounts identified for ‘funded projects’ generally and where they are actually allocated to specific projects
- Products/variants endpoint: agree in principle to use the development of V1 P/V endpoint to move towards DFC structure for data i.e. our endpoint will appear consistent / mappable to DFC, even if our data models don’t yet match that. In doing this we will set the direction for how we need to move our data models, during Network 2.0
@Kirsten to use Customers wishlist as model to develop an Enterprises endpoint wishlist
@lin_d_hop’s google sheet where we are going to start coordinating this, based on / adapting from @olivier5741’s initiative
- Work on developing script in this doc so that it is ready for Feb
- Plan is for Susan to develop an animation according to this script. This animation is primarily about communicating product vision for the platform, which obviously ties into other things, but we want to keep scope quite tight - telling the story of this direction as platform+API/interoperability = new shiny thing!