ayanova/devdocs/todo.txt

@@ -342,29 +342,12 @@ todo: many biz objects are not using new PUT methodology
 CURRENTLY DOING: 
 
 
-todo: Tax code decoupling from wo so can delete separately (almost there, a bit of testing and decisions first though)
+todo: Tax code decoupling from wo so can delete separately 
+	replace tax code drop down with a composite control instead that shows as text with an edit button when a taxname is set and just a dropdown when it's not set (null)
 
-	Test what happens when tax code is deleted and removed at back from workorderitemlabor tax id first
-	want it to be null., can that be automated with an on delete sql constraint?
-
-	should I jsut show the taxname separately as a hint *all* the time so no calcs necessary?
-	that would make shit waaay easier
-
-	Pros and cons of removing tax code id from workorder when it's deleted?
-
-	
-	Keep tax code id's as are and saving to db as it's convenient for picklist but change schema so that the workorderitem*.tax*id field is not referencing the taxcodes table
-	so that a tax code can be removed and it's doesn't break the workorder
-	also, maybe show the taxname if the taxname is nonempty but there is null in the taxcodeid as a failsafe on the form
-	(small letters underneath picklist if picklist bound to null id but has taxname: "{{taxName}}" not going to add a descriptive thing like "tax previously selected was "blah"" or something)
-	
-	also todo, if tax code is deleted it *must* be also deleted from all workorderitem* taxcodeid fields it's present on
-	maybe easiest is a constraint that removes the value when it's removed??
-	on delete blah blah or handle that at the back end on delete of tax code
-	
 todo: once settled needs to flow this back to the po and other tax code items.
-
-
+	change to composite control
+