diff --git a/devdocs/specs/core-list-graph-datatable-filtering-paging.txt b/devdocs/specs/core-list-graph-datatable-filtering-paging.txt
index 10de6512..d5a21899 100644
--- a/devdocs/specs/core-list-graph-datatable-filtering-paging.txt
+++ b/devdocs/specs/core-list-graph-datatable-filtering-paging.txt
@@ -25,16 +25,15 @@ Upon user selecting a filter to use the list query string has the regular paging
 
 
 LIST FILTERING TODO
-    - Implement this with widget list first
-    - Add DataFilter table and models and route to save, edit     
-    - Add listkey property to list??
-    - Add API route to widget list that returns the FILTEROPTIONS object as outlined above 
-        - Just a dynamic object really, no need for objects to model it I don't think as it's a one way server to client thing and doesn't need parsing or anything       
-    - Add a list route that accepts the current paging options and also a filter id
-    - A method that can take the list of field filter values and the field types and construct an sql query from it
-    - Tests for all of the above (particularly the query builder because that was a bitch with v7)
 
-    - Client side
-        - Implement filter editor dialog
+Add test for fetching widget filter options (localized, so have two users test each for expected response)
+Add test for excercising all of DataFilterController route including rights to non personal alternative owner etc
+Add test for correctly validated Widget datafilter when saved or updated via datafiltercontroller (sanity check of the filter settings and options IFilterableObject implemented)
+
+Add test for providing saved filter id to widgetlist and recieving correct filtered / paged / sorted results (test all those)
+    - Requires filter to sql code to be written and changes to the widgetlist route
+
+- Client side
+  - Implement filter editor dialog and test