ayanova/devdocs/todo.txt

@@ -22,58 +22,15 @@ FIRST CLIENT SOURCE CODE COMMIT JAN 3rd 2019
 
 # OUTSTANDING MAJOR AREAS TO BETA
 
-# NOW DOING: - finishing up the must haves
-	make sure nice to haves or not done get cased somewhere for future v.next or whatever
-	figuring out the seed data adn will it suffice for widgets required once have figured out widgets required
-		(demand drives features not features awaiting demand)
-
-
 # SEEDING ISSUES 
 
-
 seeder, make a few wo that are not completed in time in each month
 
 seeder make reminders and reviews for all users, just random scattering for now to future month ahead at least one per day to show off schedule and widgets
-seeder wo need new fields and generate data to show off and test kpi widgets and features
-	Add completed date to workorder, should be set when a closed status is set
-	used for numerous kpi stuff
-	adjust seeder to work with it so the closed state created date matches wo completed date
-
-	Also, can we calc "time to respond" based on anything extant or should there be some kind of additional field / system for that
-		i.e. maybe a workorder status is also a response status like some are closed??, then a mirror first response field like completeddate
-
 
 
 # WIDGETS 
-
-Should LIST types have a fixed limit of maximum records returned??
-	i.e. no more than 500 or something?
-	if reaches the limit then says "500 limit reached" in the list as the last item?
-
-- Widgets to make for beta in order of priority
-	**MUST HAVE***
-	
-			
-		LIST work orders filtered by status	(case 1974)	
-			this *does* make sense because it can be hyper specific to something like a "waiting for parts" status so 
-				if that is useful to a user then can see that list	
-				needs limit, could bring in thousands if not careful	
-			criteria: 
-				wo status required
-				timespan
-				tags wo, woitem
-
-
-
-	**NICE TO HAVE**
-	(these are not triaged yet)
-	
-	avg time or time breakdown by % of overdueness of workorders
-		i.e. 10% of overdue were x days overdue etc
-	avg time in each status by time period / tags
-		this could cover response time as they can just designate a status as unresponded or new
-
-	
+overdue, not scheduled should have status flags dislay