diff --git a/ayanova/devdocs/todo.txt b/ayanova/devdocs/todo.txt
index 5b5dd99d..08df0bb8 100644
--- a/ayanova/devdocs/todo.txt
+++ b/ayanova/devdocs/todo.txt
@@ -25,14 +25,6 @@ Prioritize anything that stands in the way of beta testing
 
 TODO: 
 
-Update all dependencies
-	Server section below for the AGE interval bug then can go back to regularly scheduled items
-	datatable wolist fucked
-		this is due to the AGE thing and the interval being more than a month, see if can change the age query to return total minutes or some such shit instead
-		and avoid months which is the issue here
-		also needs to see if it's affecting any intervals used anywhere else in ayanova like can you select months in a contract/pm/notification etc?
-			Weeks is the highest safe time frame interval that can be used with this but I'm almost certain there are months in there somewhere
-
 reporting issues
 test restore the big db here privately and confirm
 testing cases
@@ -252,11 +244,39 @@ TODO: 1 BETA DOCS:
                                                                         
 
 
-- 1 todo: on linux server test discovered lightbulb sample reports are coming up in listing first which is not what is expected change to z as first character and test on all platforms to confirm 
 - 1 todo: timeout is not be working, try to test it, joyce having issues
 	she's using it heavily and it's constantly locking up as in furiously processing away a stuck report seemingly without end
 	There needs to be a overall sanity timeout for this shit and I need to test it with some reports that just endlessly spin on some wait(true) type bullshit
 
+	research:
+	actually, it seems like maybe it's not the rendering process but the query itself that is slow because once the query is done the rendering is very fast
+	the bagcheck happens before the query runs so the real problem may be the speed of the query and needing a way to timeout the query or cancel it if it takes too long
+	Currently looking at workorderbiz getreportdata method to see why it's taking 20 seconds to process 100 workorders which seems crazy slow
+
+	Workorderbiz::GetReportData took ms: 26239
+
+	NEXT UP break out the fetch from the process timing wise and see which part is slowing it down
+	Before any changes:
+		Workorderbiz::GetReportData took ms: 22987
+		Workorderbiz::GetReportData took ms: 19131
+		Workorderbiz::GetReportData took ms: 28449
+		Workorderbiz::GetReportData took ms: 25477
+	Remove populate viz:
+		Workorderbiz::GetReportData took ms: 4174
+		Workorderbiz::GetReportData took ms: 3659
+		Workorderbiz::GetReportData took ms: 3811
+		Workorderbiz::GetReportData took ms: 3878
+		DING DING DING!
+	Only remove woitem populate:
+		Workorderbiz::GetReportData took ms: 4845
+		Workorderbiz::GetReportData took ms: 5026
+		Workorderbiz::GetReportData took ms: 4955
+		Workorderbiz::GetReportData took ms: 4926
+	Remove all *except* woitem populate
+
+
+
+
 	
 - 2/3 todo: there are no default reports for any objects except a selected few, thought joyce was making a report for every object that's reportable
 	will need to make a slew of default plain reports like customer etc
@@ -289,6 +309,7 @@ TODO: 1 BETA DOCS:
 - 1 translation cleanup, work order sb Orden de trabajo but is translated as Pedido?! (which is very generic and not work order, usually like a restaurant order or online shipping order sense for pedido)
 	I did a couple but realized it needs to be done one by one roundtripped carefully as it's used in alternative tenses and forms throughout
 
+-2 ops server information is missing some settings like report rendering max instances, go over the serverbootconfig settings and look for missing items to add