ayanova/devdocs/todo.txt

@@ -275,13 +275,18 @@ todo: many biz objects are not using new PUT methodology
 
 
 
-CURRENTLY DOING: 
-
+CURRENTLY DOING: Move cypress testing out of vue project and into it's own project 
 
+todo: cypress testing for load testing etc
+	Look at moving to a standalone Cypress setup, why bother with the one built into vue ui, it doesn't seem to offer any benefits to doing it alone
+	this way can be fully up to date etc
+	https://www.cypress.io/
+	Remove from vue ui project but make copy of tests first
+	then make new project folder for this and put the tests there
+	install standalone cypress and go it without vue stuff
 
 OVERALL	
 
-	- Add items below that are just spurious and not tied to a particular case as v.next cases YAGNI/TTM!	
 	- then full in front end and flow out to back end as required, remove any backend that was a defunct evolutionary path so no cruft left around
 		many UI affecting cases, some bigger than others, almost none though are deal breakers in terms of just putting all the controls on first then refining 
 		so can go whole hog on adding controls and stuff, but make sure that they are all dealt with as hideable wherever possible and in some cases need to add
@@ -293,57 +298,16 @@ OVERALL
 	- ## Try to find every thing that will matter when more collections are added now, ensure a full flow from start to stop and everything in between to try to catch any gotchas now before get too deep into it ##
 
 
-todo: cypress testing for load testing etc
-	Look at moving to a standalone Cypress setup, why bother with the one built into vue ui, it doesn't seem to offer any benefits to doing it alone
-	this way can be fully up to date etc
-	https://www.cypress.io/
-	Remove from vue ui project but make copy of tests first
-	then make new project folder for this and put the tests there
-	install standalone cypress and go it without vue stuff
+
 	
 
-todo: Translations stuff 	
-	- WorkOrderItemUnitList key added
-
-
-todo: UI wo descendants data table exposure (old v7 wo tree nav pane ui)
-	expose them as menu options from the workorderlist itself
-		so user goes to Main Workorders DataTable and in there with the extensions etc is an option to
-		 select items list from menu -> Workorderitems -> select parts list from menu -> Parts
-		 So at wo list level you can switch to items level
-		 at items level you can select any grandhild level and see a datalist for that level
-		 but only top level exposed in navigation pane menu
-	WorkOrder is *still* the main key in all these sub tables
-		Sub tables all rows have column for Workorder itself as main key / openable object for row
-		You cannot open a workorderItem for example directly, it's an entire workorder
-			though it may center upon the item as preselected row??
-			fastest system might be a "focus(atype,id)" property in Router, workorder form opens, tree is walked to find the record and the full path to it is selected at each level
-				e.g. if it's a sched user id 45 then wo finds it in the tree and then selects it's woitem first then the scheduser next in grid (if more than one of each)
-				that way it's there to edit / view from one click in the sub table grid
-		Reports and bulk ops all use full workorder object so it's up to the report maintainer how they show
 
 
 
-todo: Should workorderitemloan be included in contract discounting system??[v.Next?]
-	i.e. should *anything* that can be charged for on a workorder and which you don't directly enter a price (like outside service) be part of contracting system??
+
+
 	
-todo: how far to extend down tags, custom fields , wiki [v.Next?]
-	## UNLESS A FEATURE REQUIRES IT....MAYBE WAIT FOR FEEDBACK / IMPLEMENT LATER
-	because technically could do that easily, each child/grandchild will have own popup edit form to place those controls
-	would open shit up drastically for people to play around and add whatever fucking insane thing they want to each level
-	would certainly make Scott happy, he could put his inspection shit right in there maybe or class or whatever the fuck
-	Tags at the very least would make a lot of sense
-		really??
-	wiki might be pushing it
-		definitely
-	attachments would be kind of interesting but hmm...
-	Custom fields also probably very useful
-	People would likely want some of this to display on the list format outside
-	Would definitely want it turned off by default, i.e. no custom fields showing
-	Main thing is to be able to print the custom fields and tags which is there by default now
-	Cons: huge form, maybe too much on it??
-	Just doing units for now, will consider others later
-	## See how units turn out in UI and go from there ##
+
 
 
 	------------------------------------------