From 3d1cdedac36e1cce2c7ee83f1a4f7e9be7da05e1 Mon Sep 17 00:00:00 2001 From: John Cardinal Date: Thu, 12 Dec 2019 20:47:45 +0000 Subject: [PATCH] --- ayanova/devdocs/todo.txt | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/ayanova/devdocs/todo.txt b/ayanova/devdocs/todo.txt index 7feb868c..49e9b98f 100644 --- a/ayanova/devdocs/todo.txt +++ b/ayanova/devdocs/todo.txt @@ -45,6 +45,8 @@ CURRENT ROADMAP CURRENT TODOs =-=-=-=-=-=-= +((((((((((((((( READ HELP DOCS FOR GRIDS, SEE IF ANYTHING MISSED ABOUT PURPOSE OF THEM ))))))))))))))) +((((((((((((((( DETERMINE IF CAN USE MINIMAL SET OF STATIC COLUMNS by looking at v7, imagine it's v8 with only limited fields (hide the rest for a test view) and considering main objects and how they will show ))))))))))))))) TODO: Errors - make sure all user displayed errors have an error number if they might be something tech support needs to know (case 1854) - I guess this is a LT feature really @@ -58,10 +60,12 @@ TODO: DATE FILTER add month names for month this year case 1441 - if it's January, selecting June still means this year, not last year - Was requested at least twice, not sure how I missed it -*(((( NEXT GO OVER FEATURES AND IDENTIFY LIST RELATED AND SEE WHATS REQUIRED TO FULFIL AND DOCUMENT HERE BELOW ))))* + TODO: MAIN GRID LIST ANALYSIS, DESIGN AND COMPLETION KEEPING IN MIND TTM - WHAT is the actual purpose of the grid lists? + - WENT THROUGH ALL CASES FOR RAVEN + - Found nothing really that requires main grids other than the most basic reasons already here like selection, search, add report, so the grid columns are mostly for looking at them and creating filters - SEARCH that type of object only !!!! - Add new record of that type - Selection of record(s) FILTERED OR ALL for reporting or mass operations @@ -73,13 +77,13 @@ TODO: MAIN GRID LIST ANALYSIS, DESIGN AND COMPLETION KEEPING IN MIND TTM - Maybe a good middle ground to allow for more flexibility with mass ops is to allow up to large but arbitrary number to prevent an *all* option, like 1000 or 5000 or something which should be enough for almost anything to be practically done in segments - i.e. report on all workorders for year maybe is too large but if filter by month then can print each month separately - CLIENT for selective ops only, for any feature that is going to commonly be required to use against *all* records it should be a defined route at the server and the server should handle it when client triggers - - Features requiring mass ops: - - + - COLUMNS DISPLAYED - Crtical columns are the name or equivalent that is unique as the primary item - Other columns that are critical would be any that are stock and required - Leaning toward static fixed column display that is sortable + - Not seeing any real reason to have many columns other than for viewing purposes and filtering which can be done outside of the grid - Should users be able to set columns or am I really going to force it to a preset? - I had a customer today request the Description field from unit show in the workorder service grid, it doesn't do that