diff --git a/devdocs/todo.txt b/devdocs/todo.txt
index 9f2a548c..995d7d42 100644
--- a/devdocs/todo.txt
+++ b/devdocs/todo.txt
@@ -5,41 +5,40 @@ eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOiIxNTcxODU5OTU0IiwiZXhwIjoiMTU3MjQ
 
 ## IMMEDIATE ITEMS
 
-
--------------------------------------------------------------------------------------------------------------------------------------
-Need a sprint to get to a fully testable client with entry form, list and as much as possible all features from COMMON-* specs list 
-Do the stuff in the Client todo first then back to the server as required.
-
-CURRENT MASTER PLAN IN CLIENT TODO
-REALLY MAKING MORE PROGRESS WHEN CLIENT DEV DRIVES BACKEND DEV, STICK TO THAT!!
------------------------
+Continue work on widget->user->email list
 
 GRID LISTS TODO NOW:
 	- Make a joined table list for development 	
 		- Widget list with User and their email
-	- Make regular list of widgets with all columns no joins as second list
-	- Once both lists are working, abstract away the commonalities into other classes
-	- There's going to be a fair number of data source lists in routes so..
-		- NOT immediate issue, but once the lists are working...
-		- Do I make a route for each one or user provides a key of which list they want and that goes into a single route to return the data?
-		- What about when there are dozens of reports, do they all hang off each object type controller or is there just a central data list route for all combined?
-			- i.e. if I want to make a widget->user->Email report and a separate user email report are they each in widget and user
-			- Or, because they are read only lists used for many things do they just go into a central route for read only lists?
-			- Also rights issues might affect this..?
-		- One central route with keys would simplify the client end UI certainly
-		- Maybe all WidgetController routes are only for CRUD (and mass change) ops and not for list retrieval?
-			- Would simplify the WidgetController and biz for sure
-		- one central route would get pretty huge though, will be clearer once I abstract out the bits
-			- Maybe instead of the objectFields monolithic class I have one small class for each list and or UI editing definition that all feed into a central spot
-				- This way each type is in it's own file and cleaner?
-		- UI custom fields and shit part is kind of separate from the list stuff with only a bit of overlap, maybe they are separate objects once again and split out?
-	- Update tests when appropriate (when it's working fully and not mocked)
-	- Mock return objects for now with the new fields to include in the response see core-main-grids.txt and core-display-format-template-system.txt
+	- Make regular list of widgets with all columns no joins as second list	
+	- return the lists properly as objects as specified
+	- UnMock MOCK_WIDGET_DISPLAY_TEMPLATE_JSON into db with objects and with seeded data for test and or all lists
+		- One single object with all templates in JSON maybe? since there are not going to be multiple templates for same list object anyway
+			- Server can load it up and cache it like LT?
+		- Can it just make a default template if none is found?  (no they are all required)
+	- Once both lists are working:
+		- abstract away the commonalities into other classes
+		- REFACTOR: There's going to be a fair number of data source lists in routes so..
+			- NOT immediate issue, but once the lists are working...
+			- Do I make a route for each one or user provides a key of which list they want and that goes into a single route to return the data?
+			- What about when there are dozens of reports, do they all hang off each object type controller or is there just a central data list route for all combined?
+				- i.e. if I want to make a widget->user->Email report and a separate user email report are they each in widget and user
+				- Or, because they are read only lists used for many things do they just go into a central route for read only lists?
+				- Also rights issues might affect this..?
+			- One central route with keys would simplify the client end UI certainly
+			- Maybe all WidgetController routes are only for CRUD (and mass change) ops and not for list retrieval?
+				- Would simplify the WidgetController and biz for sure
+			- one central route would get pretty huge though, will be clearer once I abstract out the bits
+				- Maybe instead of the objectFields monolithic class I have one small class for each list and or UI editing definition that all feed into a central spot
+					- This way each type is in it's own file and cleaner?
+			- UI custom fields and shit part is kind of separate from the list stuff with only a bit of overlap, maybe they are separate objects once again and split out?
+		- INTEGRATION TEST UPDATE Update tests when appropriate (when it's working fully and not mocked)
+		
+
 
 
 
 
-TODO: return the list as objects as specified
 
 CLIENT CUSTOM FIELDS CHANGE
 	- Must use numeric instead of text values now
diff --git a/server/AyaNova/biz/WidgetBiz.cs b/server/AyaNova/biz/WidgetBiz.cs
index acdf4737..66ce051d 100644
--- a/server/AyaNova/biz/WidgetBiz.cs
+++ b/server/AyaNova/biz/WidgetBiz.cs
@@ -414,8 +414,8 @@ namespace AyaNova.Biz
             //TODO: Get template (MOCKED FOR NOW UNTIL PROOF OF CONCEPT)          
             var MOCK_WIDGET_DISPLAY_TEMPLATE_JSON = @"
             {
-                ""full"":[""WidgetName"",""WidgetSerial"",""WidgetDollarAmount"",""WidgetRoles"",""WidgetStartDate"",""Active""],
-                ""mini"":[""WidgetName"",""WidgetSerial""]
+                ""full"":[""WidgetName"",""User"",""UserEmailAddress""],
+                ""mini"":[""WidgetName"",""User"",""UserEmailAddress""]
             }
             ";