ayanova/devdocs/todo.txt

@@ -5,6 +5,35 @@ Success is the ability to go from failure to failure without loss of enthusiasm
 "A smooth sea never made a skilled sailor" Franklin D. Roosevelt
 
 
+
+BIG PLAN
+
+1) Get the widget edit form completely working with the exception of reporting which can be stubbed out but should be present even if not functional now
+	- nothing left to determine, ready to copy to other objects and automated testing
+	- Test manually with all devices before baking it in
+
+2) Scaffold the shell framework completely in place as much as possible so that we know there will be minimal other changes required
+	- All areas stubbed out now even if empty, just so you can see it and know what needs to be fleshed out and for demo purposes
+	- Test manually with all devices before baking it in
+
+3) Get the Widget list and filter and any other options (except reporting) fully working and ready to roll out.
+	- Nothing left to determine, all done, ready to copy and automated test, with a stubbed out reporting UI
+	- Test manually with all devices before baking it in
+
+4) Reporting - figure it out, flesh it out, make it happen
+
+5) Licensing / Rockfish get this ready with Rockfish to be able to license it in reality so it's ready for 3rd parties
+	- Test the full trial / license business cycle and confirm it's solid and integrated into the Rockfish database properly
+	- Doesn't have to be perfect, just working enough for the real world, can make it easier or nicer later
+
+6) Look for anything major missing at this point, make it deployable as a package and test the deployment on a raw server
+	- need to know it will be ready for 3rd parties to try out as much as possible.
+
+7) Start adding the real shit and the corresponding v7 import code for that shit
+	- This is when the build and test cycle really starts hitting stride
+	- Goal at this stage is to build a testable deliverable on a regular basis with a new section of stuff added periodically
+
+
 NEXT TODOS:
 
 
@@ -25,25 +54,51 @@ DONE (for widgetlist grid and basic views): VIEW PERSISTANCE / STATE
 			- On the other hand the scroll position should not survive a session and should be cleared
 				- We don't need to worry about this for the pages in theory as there is a built in method used in router to enable it which seems flakey but it's the way to do it
 			- Focus only on the type that survives a session for now, the rest as required
-TODO: ADD NEW WIDGET 
+DONE: ADD NEW WIDGET 
 	- Add new record button to the edit form for a widget
 	- Hook up new record button on top of widget list
 	- Code for new record to the server
 	- Need a path to making a new record
 	- ID 0 maybe
-TODO: New widget exposes issue with empty dates and the picker, it gives an error if the date is empty
-TODO: Fill selection boxes, autocomplete etc
+DONE: New widget exposes issue with empty dates and the picker, it gives an error if the date is empty
+TODO: Fill selection boxes, autocomplete handling etc
+TODO: TAGS!!! Do tags mofo
+TODO: Record history display / check other AyaNova 7 options / buttons that need to carry forward
+	- Some of this stuff is stage 2 for the edit form
+
 TODO: NOW THAT FORM IS THERE MOSTLY, CLEAN UP CODE FOR RE-USE in many other forms
 	- Don't need to replicate common code so put it somewhere else
 	- formstate shit is also menu shit really so can they be combined somehow, like present two sets of menu options one read only and one fully read-write?
 		- some forms will have special needs but could handle them outside of the regular boilerplate shit?
-TODO: INVESTIGATE - DO I need to institute a back button? (in APP MODE?? installed to "desktop" on device will I be able to easily navigate without back and forward buttons)
-TODO: History button, other AyaNova 7 example buttons all need to be there or their equivalent, do we need a top menu type thing?
-TODO: TAGS!!! Do tags mofo
-TODO: //todo: timezone doesn't match, offer to fix it in initialize.js there needs to be a prompt and autofix
-TODO: Automated testing of UI by driving web interaction, that needs to be instituted asap
+TODO: Outstanding case with vuetify bug in clear button when readonly, check if fixed and if it isn't might need a workaround
+
 TODO: Server needs to do widget validation 666 test rules not only in debug mode so can test when put up to the devops server
-TODO: Dark mode (dark with a half moon icon)
+TODO: INVESTIGATE - DO I need to institute a back button? (in APP MODE?? installed to "desktop" on device will I be able to easily navigate without back and forward buttons)
+TODO: INVESTIGATE / REDO THE TOP LEVEL SHELL - TIME TO MARKET / Is my shell layout fucked?
+	- wouldn't it just suck to have all those lists exposed at once in inventory?
+		- Opening that page once they are all there would trigger huge traffic to the server, better to confine things to their own area as much as possible
+	- TTM: isn't it faster to just turn the menu into a tree like v7 or put options in each one's screen? (Like inventory page just shows a bunch of other icons to open details like widgets)
+	- TTM: I'm concerned that the modular UI is a bit too ambitious, yes it makes sense for re-usability but exposing it to users so they can redo their UI seems crazy ambitious at this point
+		- People just want to work and simpler is always better, less to maintain
+	- How about the easiest simplest layout possible even if it's a bit uglier but keep it all clean and focused instead of too much shit on each form?
+	- Really, for maintainability it makes sense to have a very simple clean layout and not try to put a bunch of complex controls all over the fucking place!!
+	- I need to make money from this, not win prizes for design!
+	- Easier to show or not things for authorization purposes when they are each in their own navigation path as much as possible
+	- users are used to a certain thing with v7 why re-invent the wheel, just clean it up and modernize where necessary
+	- There are so many other things I need to focus on, this is just adding complexity in an area that might be a nightmare to maintain and troubleshoot.
+	- Sounds like my minds made up, this issue is more about changing the SHELL UI
+
+
+
+
+TODO: Automated testing of UI by driving web interaction, that needs to be instituted asap
+	- However, until the shell is worked out it might be best to hold off, that's why I put it below the shell stuff above
+
+
+TODO: INVESTIGATE - Dark mode / theming (dark with a half moon icon)
+	- If it can be done with a half hour of work and doesn't affect anything support wise or maintainance wise then yes
+	- Also see how to allow theming maybe or colour choices?  Nah, dark mode is the most useful; I should decide the colours and stick with them it's part of our image
+
 TODO: Grid / LIST VIEW = I know customers will want to control what shows in the list views (grid equivalent in v8).  
 	- I had a customer today request the Description field from unit show in the workorder service grid, it doesn't do that
 	- Customers probably want the option of picking what fields show and what don't
@@ -52,17 +107,23 @@ TODO: Grid / LIST VIEW = I know customers will want to control what shows in the
 	- Maybe list objects also return a list of fields the current user will expect to see so the list can be pre-set up with the columns at the client *then* the data fetched to populate the list
 	- Server should not send fields that are restricted or have them blocked out or something.
 DONE: Grid list view should be easier to open, the open button should not be at the far right but more of the whole entire element or a larger portion of it maybe?
-TODO: Outstanding case with vuetify bug in clear button when readonly, check if fixed and if it isn't might need a workaround
+
+
+#locale stuff
+TODO: //todo: timezone doesn't match, offer to fix it in initialize.js there needs to be a prompt and autofix
 TODO: code the user options with the currency symbol etc on the server and then update client to fetch them.  Use static values instad in locale.
 Locale should fetch those settings the first time it sees they are not present so that they are refreshed upon use and are not stored in localstorage
 (or should they be?  anyway, can work that out later)
-TODO: License trial handling front end code to make my life easier
 TODO: Local user settings page / UI where can 
 	- set locale choices and values
 	- Reset to default form settings
 	- Other shit I can't think of right now but there will be a lot
+
+TODO: License trial handling front end code to make my life easier
+
 TODO: Add formstate data to technical support information
 
+TODO: Need to do all outstanding edit form stuff next 
 
 ### RETEST ALL DEVICES WHEN GET TO HERE #####
 TO TEST: