From 7bbafb7cadff469df7abfc71e10da8d6f4251b97 Mon Sep 17 00:00:00 2001 From: John Cardinal Date: Wed, 6 May 2020 21:00:59 +0000 Subject: [PATCH] --- ayanova/devdocs/todo.txt | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/ayanova/devdocs/todo.txt b/ayanova/devdocs/todo.txt index fbab4777..5683f000 100644 --- a/ayanova/devdocs/todo.txt +++ b/ayanova/devdocs/todo.txt @@ -84,6 +84,8 @@ Finish off the v8 test export then get the below shit done so can move to stage todo: PLANNING WORKORDER considerations: + QUESTIONS: + Why do I need to make a wo first before I can update it? (i.e. why did I make a CREATE route?) DEPENDENCIES Workorder is not dependent on it's children for anything @@ -128,10 +130,21 @@ todo: PLANNING WORKORDER considerations: labor 2 (OP flag = "update" with all data) labor 3 (OP flag="delete" with concurrency token and nothing else) labor 4 (OP flag="Add", with all PUT data) - + SERVER + Server accepts graph at single WO POST route (since it's not a put) + UI + ui manufactures the return object with the OP fields by doing dirty tracking on changes + UI - Ideally I would like to only send the bits that are altered to save bandwidth + Only send the bits that are altered to save bandwidth + All updates are technically a PATCH operation + Because it starts with a wo object provided by the server? + or is this even necessary now? + think Patch + CONCURRENCY: + if any part of the patch fails the whole patch fails + A biz object for each one? probably need the parent for biz rules and shit so likely best to keep in one file @@ -254,6 +267,11 @@ todo: PLANNING session tracking to prevent logging in from multiple devices with +todo: Server serialized fields, it should *not* be getting the value from the table but rather have it's own table with last number assigned instead + My plan has flaws, getting the number from teh last number used in the actual table is a bit fucked because it means you could end up with mutiple issues + Instead have central location for storing serial numbers (perhaps one per table type for concurrency efficieny? Though it's a pretty fast operation.) + Do not put in shared object though, i.e. global settings or something because it's going to be it's own thing and require efficient access. + Maybe this is a case for a stored procedure? History - MORE button not showing? Was looking at administrator history for AA import scott - also, is it showing other types of objects besides Users and Customers? (not seeing wo)