admin/raven-client
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
ffb935f88bdf3c2fb183d34e2afea8dcb124be76
raven-client/ayanova/devdocs/todo.txt
John Cardinal ffb935f88b
2020-02-22 00:53:43 +00:00

768 lines
48 KiB
Plaintext
Raw Blame History

# CLIENT TODO
**************************************************************************************************************************************************************************
CURRENT ROADMAP
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
- Test manually with all devices before baking it in
- Make automated test for it
2) 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
3) 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
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
- READ THIS: https://medium.com/@gokulrajaram/self-serve-first-the-overlooked-but-essential-paradigm-underlying-great-software-companies-45a67dbec4c4
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
- Invite feedback and beta testing
8) BACK END Self Serve readiness
- READ THIS: https://medium.com/@gokulrajaram/self-serve-first-the-overlooked-but-essential-paradigm-underlying-great-software-companies-45a67dbec4c4
- licensing changes for a online hosted app
- Self serve process in place
- Ability to upload v7 data from DataDump plugin
**************************************************************************************************************************************************************************
CURRENT TODOs
=-=-=-=-=-=-=
TODO: PLAY WITH QUERIES, if search for pizza in name bombed at server
- SERVER: when the query bombs with exception it should output the query text to the log and console (DEV MODE)
- do same thing not in dev mode but in higher level of logging? though more ideal if it returns to client so I can see it remotely
- Maybe still a good idea to return generated query in case of fail for diagnosis
TODO: ListView editor hasn't had SAVE code written yet
TODO: CACHE dataListAvailable Fields at least on one temporary cache for most current
- This is because the listview editor needs it and if a user is flipping back and forth between
the datatable and the filter getting it just right they will be triggering a fetch over and over
UNSAVED STATUS IN EDITOR
If start with saved filter, as long as user is editing it keeps same name until they leave without saving then it becomes unsaved with -1 id
- So while in edit form can save or not their choice
- If leave without saving converts to unsaved filter at that moment so back at datatable form it shows as unsaved filter
- No prompt to save? Or change text to say will continue as unsaved filter
- How to cancel changes then?
ListViewEditor
- Edit list view, can also duplicate to create fresh one
- gets listviewid and datalistkey on route
- INIT
- First GET DataListFields for the DataListKey from DataList ListFields route (query string DataListKey value supplied )
- This is the pool of available fields
- Second get the ListView that is currently in use so can setup the page view
- If listviewid is zero then that's starting with the default list view so need to fetch it and then init the form
- If listviewid is -1 then that's staring with an unsaved listview so get that from the saved form store
- If listviewid is greater than 0 then it's a saved listview and there sb a cached version of it but ideally maybe fetch it from
- Third: Make up the working copy array that the UI is tied to
- Fourth: when the working copy array changes that should trigger the UI to draw accordingly
- Editing
- Editable fields: Name, Public, ListView
- Default fields: UserId, ListKey
- any changes to UI objects affects working copy
- Also the cached listview stuff needs to be changed so if user leaves form and goes back the changes are immediately seen in the datatable
- Put unsaved listview into formsettings and set id to -1
- Any field set to a filter or sort is also autoamtically visible and can't be set invisible
- Each field has optional array of filters
- Each field has optional sort toggle plus minus or unsorted (could use icons for this)
- Saving
- process working copy to generate a ListView suitable to save and save it
- Dont' include items not set to visible
- On save set formsettings listviewid to whatever the id is and put listview into temp cache and clear out unsaved listview
- duplicate
- Make a listview and save under new duplicate name or however Widget was coded (makes a default then user changes name I guess)
- set formsettings listviewid to duplicates new id and clear out formsettings unsaved listview and put formsettings listivew into cache
- delete
- Remove listview from server, fixup local formsetting to use default listview and id 0
- WORKING COPY ARRAY FORMAT
- Need all fields available in it.
- Each field is in order determined in UI (user can re-arrange order so need UI method called with circular buffer)
- Each field has
- visible property
- filter array (optional)
- Sort property -+ (optional)
GZFORM FORMSETTINGS RELATED TO DATALISTVIEW
- formSettings.saved.dataTable.{listViewId:[0 if none or else the last saved view id selected], unsavedListView:[edited but unsaved listview json, only if listviewId=0]}
- formSettings.temp.dataTable.cachedListView - temporary cached version of listview that was saved at server but only if saved listviewId is non-zero
DataTAble form inits listview as follows:
- Checks if there is a current active unsaved listview in the formsettings for that form and uses it if found
- If no active unsaved listview it then checks for an ID of a listview in formsettings last used and fetches and uses that if found
- If no current unsaved listview nor an ID then it just leaves that blank and let's server use default listview
If user selects to edit listview then ListViewEditor inits as follows:
- Checks if there is a current active unsaved listview in the formsettings for that form and uses it if found
- If no active unsaved listview it then checks for an ID of a listview in formsettings last used and fetches and uses that if found
- Also sets in selection list of listviews (or is that in thsi form)
- If no current unsaved listview nor an ID then it fetchs from the server the default listview and uses that in the form
If user leaves listview form without saving:
- If any changes were made then ListViewEditor persists that listview to the store under the formsettings specified so that form can pick it up
- If no changes were made then nothing is persisted
If user saves view from ListViewEditor
- Overwrites with prompt if they save to same view
User opens datatable is presented with default listview arrangement
Until user opens listview editor the datatable uses the default and doesn't persist a listview
If user opens a ListView editor without any local customizations then it fetches off the server and presents as the default for that DataListKey
If Client makes any changes to a listview they are persisted as a formsetting for that datatable that survive a restart
When datatable form is opened it checks if a persisted formsetting of listview, if found sends that with the request for the list, otherwise listview property is empty
If user selects a listview from the server for the datatable as long as they don't edit it that listview's ID is stored instead in the formsetting.
The moment they edit a listview it's stored in full in local formsetting as the current active.
Client stores the active listview into the persisted formsettings if there are *any* customizations done
Filter UI
- Works with a passed in listview array somehow (from STORE I guess, current list view kind of thing?)
JSON DataListView format:
ONE string of json, not separate
Contains all columns that are relevant each as an object with various props desired to be returned in order
If a column isn't filtered or sorted or included then it isn't in the collection
Order and presence determines sort, filter, return and display order
Each column object contains it's sorted, sort order and filters collection which can be empty
Sort and filter properties are optional and can be omitted
"any" property is optional in a filter and can be omitted
UI: shows all available columns, user sets order by re-arranging and whether to include or not with a checkbox Include which defaults to true if there is any conditions on that column
ID COLUMN FILTER:
These columns could filter by text or by "SPECIFIC" ID so support that:
TODO: DataFilter how to distinguish between filtering on specific ID value or on value column
- Might need to add a filter on ID type of thing maybe?
- This works in v7 by providing a list of items that were displayed for that object in the list so that they can select the particular one and that item's ID is then saved for that column
- For v8 since we know the type of the column we could in theory fetch a list of all items of that type on demand for user to select from if they choose to go that way.
- This way the item doesn't need to be in teh source grid like in v7 so it's actually better!!!
Example:
DataListView JSON:
[{key:"COLUMN UNIQUE KEY ID",sort:"-" or "+",filter:{any:true/false,items:[{FILTER OBJECT SEE BELOW}]} }, {key:"second column unique key"},{...etc...}]
Filter object definition:
Has an "any" boolean property which if true means make an OR query of the conditions if more than one, if nore present or false it means AND each condition (if more than one)
filter:{any:true/false,items:[
{op:"OPERATOR",value:One of an array of strings, single string or single value of any supported type, i.e. int, decimal, bool iso8601 date etc }
]}
Filter operators:
public const string OpEquality = "=";
public const string OpGreaterThan = ">";
public const string OpGreaterThanOrEqualTo = ">=";
public const string OpLessThan = "<";
public const string OpLessThanOrEqualTo = "<=";
public const string OpNotEqual = "!=";
public const string OpNotLike = "!%";
public const string OpStartsWith = "%-";
public const string OpEndsWith = "-%";
public const string OpContains = "-%-";
public const string OpNotContains = "!-%-";
TAGS - At server if equality compare value is an array of strings then it's assumed to be tags, if it's a single value then it's regular
Sort / filter / select return columns all in one!
- This combined is a "view" or DataListView (fucking renaming again here we come! :)
- When user opens a data table they see for the first time the default table view and sort order and filter (no filter, sort by id, a few key fields)
- they can make a new view which shows all the fields and they can set props on each one:
- Filter (with filter code)
- in v7 users can set more than one condition per column by selecting "custom" so we need to support that
- Maybe a row of all columns then each one has a expandable list of conditions under it for setting multi filters?
- Like a card with top part all static info, then filters below as a collection that can expand the card vertically with ADD and REMOVE buttons for each one
- In v7 user can set AND or OR query for custom more than one condition (but it applies to teh whole group, not both and and or individually)
- Sort
- View order is sort and filter order
- Visible
- Checkbox if visible which means the server returns it or not, visible maybe not correct word here
- This way the user can customize the grid all in one savable setting
- Grid defaults to last "View" that was in use
- REPORTS
- Report object has following properties:
- DataList name it's based off of
- Required fields from DataList
- Report template itself with it's own code and template requirements TBD
- Report columns returned: When user selects to show a report, client will fixup any missing columns from the datalistview currently in use
- For example they are viewing a table based on a TestWidgetDataList DataListview with only 3 columns in it
- They drop down the reports list which shows all reports based off TestWidgetDataList view
- They select a report to print.
- Report code looks at report's required fields from DatalistView and sees report uses 6 fields listed
- Code compares report fields to in use DataListview fields and appends any report required fields missing from current view to the right of the collection in the current DataListview
- When report is run it will have all fields this way returned but will still be sorted and filtered by table view
- As part of editing process user can select an existing datalistview to prime their report editing view
- A report can be selected from any client table that is based on the same view
- MINI code is not right:
- right now it produces a single column header but can contain multiple columns of data
- this is bad because the client doesn't know the underlying type so can't co-erce each column into locale format
- I'm thinking ditch mini at server and make it a client display issue instead
- There does still need to be a MINI default format though for all lists, hard coded so user can revert or start with a solid PickList
- MINI just same as regular DataListView however Client would display differently munged into one column so up to user what columns in what order!!
- So we need two default views for each datalist, one for grid display and one for picklist display that can be reverted to and are permanent
- User can at any time use the default view or pick a custom DataListView
- All users start with default view and can modify as they see fit
- each form with each picklist would have it's own view possibly?
- IS MINI options a different UI?
- Maybe it *is* different because selects are a kind of unique situation with thier own requirements.
- Can default but also would be hellish if it's customizable user by user since there is probably a company standard for selecting parts for example
- Maybe the "Default" can be set by an admin and users can either select default or go off the books to their own custom
- Reports are a special circumstance, a report really would go with a specfic filter wouldn't it? INVESTIGATE THAT
- View filter set with report? Report needs all fields sometimes but view may not have so what happens then?"
- Show text filter sort fragment at bottom of grid in footer
- PickList of filters for dataListKey (DO I have a server route for that?)
- ListOptions editor
- OWN PAGE NOT combined with data table
- Data Table just has the selection for presaved filters
- UI allows to edit both filters and sort order
- FILTERS: needs to take a list of available fields to select from, pick on adds to collection then can set actual OP and VALUE etc stuff on it based on type
- Build from new, rehydrate view from existing, handle bad column names no longer valid
- uses standard filter column definition to feed UI elements, ideally not a composite array that needs transformation
- See custom fields builder as that is similar
- Code as an component element, perhaps made of other components?
- SORT
- In same UI as the filter builder, probably the most commonly accessed of the two so maybe sort order on top and filter below?
- ListOptions builder
- Need method that builds the list options into json fragments to send to server with datalist request
- ListOptions descriptive text builder
- A Way to show a string of text showing what filter options and sort options were chosen so can be output to reports etc
- DataTAble UI
- Pick list of ListOptions for that list type at top also (no options) empty default choice
---------------------- NON DATALISTVIEW STUFF ----------------------------
TODO: "Unsaved filter" being displayed, sb "Unsaved listview"
TODO: Switch control has issues in mobile view throws error "touch is undefined"
- Update and see if fixes or else switch to some other component
TODO: HELP link on listVieweditor not working
TODO: Add test for *NULL* and not *NULL* in datalistfilter tests as there currently aren't any
TODO: ay-data-list-view initform code shows proper way to initialize and await each step
- Take that model and look at all the other forms and ensure they work the same way
TODO: Tag picker a bit buggy, when you type to search it retains the typed text in the entry box after selecting, it shouldn't
TODO: Custom fields test it out with grid, will likely need some field type code etc or is that already in the columns, not sure
TODO: Tags in grid display, currently shows as an array of raw text with quotes, could be better displayed
TODO: Select in grid fuckery when changing formats or switching between Listviews seems to trigger selection for some reason
- MAKE LT() method in forms available to all vm users so don't have to keep defining it in every single form
- Make functional user settings form with all overrides so can test shit out
- Need a browser check on opening the login page that will check to ensure the browser can do the date conversions properly etc and tell user browser is unsuitable if it isn't
TODO: Created hook is probably where I should be doing the stuff I'm doing in beforeCreate hook, test if can simply move it in widget edit form to created
- Reason being that the data object is not fully set up in beforecreate but I'm putting data into it as if it is which seems weird
TODO: CUSTOMIZE not working on widget edit form
TODO: CUSTOM DATE FIELD NOT SETTING NOW??
- Retest every kind of custom field
TODO: toolbar above grid for filters, refresh etc (make it a standard component?)
TODO: SEARCH UI
TODO: Make sure scroll position is respected and saved when editing a widget and coming back to the list
PICKLISTS:
TODO: CLIENT PICKLIST DATALISTVIEW selector form
- Will need under useroptions a central location to choose all datalistview for every type of picklist in AyaNova
- User can leave at default or select a saved DataListView (or make one there) to use
- Client will then pick up that format in any form where it's required
TODO: MAKE PICKLIST COMPONENT Select lists and filtering by tag "select-search-filter-control"
- Implement it as a component with built in searching and tag selection that is sticky by individual form item
- this is an important crucial item and needs to be easy and clean
- I'm thinking it auto searches by entry like RI, but you can open more UI and select tags to filter with it
- Or maybe it's part of datafilter too?
- See add food filter in diary in chronometer app for inspiration (though theirs is a bit dumb, you can only select one tag)
TODO: Utilize new picklist in Widget form to select something that exists and can then test out DataListView etc
TODO: Client API code handle ?? (NO IDEA, maybe meaning update client after all changes at server?)
TODO: Make errorBoxError message box on all forms a component instead as it's just boilerplate
TODO: TIME ZONE MISMATCH MESSAGE
- This is actually quite important for relative date filtering lists
- Make it automatically set the time zone offset by a actionable click on the time zone mismatch message
- This way user knows it's happened and does it on purpose when appropriate
- Or user can ignore it and just keep working in their chosen time zone but will be aware it's an issue
- It may need a logout and back in unless it can just set the local setting which I guess it can, be aware of that anyway
- Time zone mismatch message sb localized and far shorter
TODO: Workorder/quote/pm templates
- Put the link to access them into their own type, i.e. Workorder templates are accessed from either the grid listing workorders or inside an individual or perhaps BEST IDEA in the NEW menu where you pick a template !!!!!
TODO: Hover / hint text on copy log and log buttons (and possibly others?)
TODO: Modify underconstruction to support alternate size image
- right now it just cuts off on smaller form factors, would be much nicer and cleaner if it shows responsively
- Important because it's going to be seen by beta testers
- https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images
- https://vuetifyjs.com/en/components/images
TODO: SERVER STATUS
- check server status on attempt to login for first time or whatever, it should give a prominent warning if the server is unavailable due to closed for maint or whatever rather than just timing out.
- Also it allows login which is good but it should restrict the UI if it's a fresh login to a closed server rather than just failing to do certain things
- Maybe overall testing is needed with a closed server just to suss out what to do in the UI for that, we want ops people and admins in there but not other biz users if it's locked out
- Maybe an alternative page when it's locked out instead of the normal view of each view saying server down for maintenance or something
TODO: Why is there an error in the console when a user is not logged in and opens client?
- It should just go to login, no error should show in the console
TODO: ANY TIME - SIDE v7 STUFF DataDump plugin needs an explanation of what it is in the flow, right now it's completely cryptic and people may be using it for stuff thinking it's for something it's not
- Also, verify it's manager account only that can run it or maybe someone with total rights to everything?
=================== FINALIZATION OF EDIT FORM BEFORE "STAMPING" OUT MORE ===========================================
TODO: VET translations
- There are still a large number of non translated lt's in the non english stock languages (i.e. "More...")
- Make it easy to dump the local storage locale text for vetting the translations
- Login as each language, exercise the entire UI and then dump all the locale text that was fetched from teh server and look for non english words
TODO: REPORT LIST
- Stub out some fake reports in a drop down selection for testing, doesn't have to do anything but be present
- Test on mobile once done
- WAS implementing as a dialog, that needs to be replaced now, either I need to follow the vuetify dialog example and put it in the shell app.vue or I'm going to use the dialog library I already have once I get an answer on templates
- If I use the vuetify example it means there needs to be a dialog in the shell that is activated from any form inside it but it also needs to be bound and shit and won't be very clean
- If I use the library dialog component and figure it out in theory it will just popup when required and not pollute the shell template with anything. I guess it inserts itself into the dom.
- NEED to think about this one, can't put thousands of reports in a list in the menu
- One idea I just had is maybe the last report used for that form is surfaced on the context menu in addition to the regular reporting option
- If take last report used then it directly opens a preview
- If take generic Report option then it opens to another form for choosing the report and whether to print or not etc
- SB localized in form as "Report" not "Print" because it's going to be likely that people will want to work with pdf (email, download) instead or just the view of it, print is maybe not a common option.
TODO: WIDGET EDIT FORM SAVE AND NEW BUTTON LIKE V7?
- NO, just keeping this until I get here in case I think I need it again, don't need it.
TODO: RECORD HISTORY
- implement in stubbed out separate page
- Record history could be displayed on a timeline: https://vuetifyjs.com/en/components/timelines
- Defaults to showing most recent stuff first in order to satisfy most common requirement of who last edited
- Probably going to need a server route but let the UI drive it (timeline view requirements maybe?)
TODO: ADDITIONAL EDIT FORM BUTTONS FUNCTIONALITY STUBBED OUT OR MADE INTO TODO'S
- Check what is in v7 that I missed on edit forms, make TODOs for them here
- Check what is in RAVEN STAGE 1 cases on RockFish and make TODOs for them here
- implement and componentize
TODO: WIKI
- Implement in stubbed out existing separate page
TODO: ATTACHMENTS
- Implement in existing stubbed out separate page
RETEST HERE ON ALL DEVICES
TODO: AUTOMATIC TEST *** SUPER IMPORTANT *****
- Once widget form is solid then need an automatic UI test for it to get that ball rolling and to ensure no slips during development
- Ideally it will test every input component and validate the entire record round trips properly, maybe it needs to also try different states like creating new, editing etc
- Also function as a "smoke" test that will heavily exercise the server and client repeatedly for as long as I let it run which will reveal issues before releases
TODO: Locale page with locale settings
TODO: Trial route ui support in client (ON HOLD NEEDS BACKEND WORK)
- Went to do this but found it's a bit of a maze and has some hacked temp code in the license fetch route etc for development purposes
- Need to determine what the actual solution is for production and make some changes at the backend first
- Also this might be the point to start looking at RockFish changes as well
- Add an area to support refreshing the database and generating test data
- Would be useful to see and manage OPS things related to deployment to server just to save time, can refine them later
=========================================================================================================
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.
- DON"T get too fancy with this, my instinct is to make it more complex all the time, but actually ugly and simple and effective is better than pretty but fucky to use
- Also, mobile really doesn't go well with fancy but more with clean and simple.
- Sounds like my minds made up, this issue is more about changing the SHELL UI
- IDEAS:
- old fashioned switchboard kind of thing, big buttons for each area sit in a row, on mobile they are vertical full width?
- ugly but effective
- Alternative is a Tree control in menu instead, but that would likely be ugly in mobile(could investigate but it's not common probably for reason, look at material apps on phone see what they do)
- Don't worry about having to navigate too deep with too many clicks for the top level, yes some won't like it, but it's more important to focus usability and minimizing clicks in the actual path that day to day users take
- In other words make the most common tasks quick to do from the top level / HOME screen perhaps and *thats* where to focus on customization so users can surface what they want there as a LINK
- Users can modify what shows by default in the home screen but not the fancy active widgets I had envisioned but instead different task based buttons / links so they can get to where they need to go quickly
- e.g. click on inventory, select the Widgets switchboard button, the widgetlist opens full screen to the right side, one of the menu options is "Add to home screen" with a favorite button
- They click on add to home screen and next time they are on home screen a new button / link is there to that item, autoamtically pre-grouped by area of functionality or maybe they can just order it how they see fit?
- I really like the idea of the widgetlist being full screen to the right rather than in a component sharing that space as it's pretty necessary
to have a lot of columns display at times, yes it's a ui made up of a bunch of lists but that's really what people understand, it's appropriate to the application,
no business software can simply hide everything and it doesn't have to suck or be ugly
TODO: Clean up TODO list, have only actionable, not completed items.
- Make a to_test.txt doc so can move todo's to to test doc for testing
- anything in this doc that isn't related directly to individual todo's other than a small big picture stuff at top sb elsewhere
- Idea is to have a focused, clean actionable list here.
- Prioritize any basic stuff that will be replicated over and over again
- i.e. regular edit forms, not schedule or workorder form which will require their own separate work and are not replicated
- want to get going with all the background object types like clients and users etc before I try to make the schedule and workorder forms
- Identify any unique time consuming items and put them in their own block of todo's
- Self serve server stuff
- workorder form
- Accounting integration and other plugins
- import datadump etc
- There is a lot of crap at the bottom of this document in this todo!
TODO: NOW THAT FORM IS THERE MOSTLY, CLEAN UP CODE FOR RE-USE in many other forms
- Look for things to componentize
- Can I componentize the whole form itself so that I have all the basic requirements built in and can just customize certain things for each object type?
- Look for things that are not specific to the widget edit form but can be abstracted away for other forms
- Don't need to replicate common code so put it somewhere else
- Are any of the controls better as a component and self contained to save the size of the form code and complexity?
- What I mean is, for example, a text entry field could be standardized then re-used as a component if it's props and settings take up so much space etc
- 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: Outstanding case with vuetify bug in clear button when readonly, check if fixed and if it isn't might need a workaround
- They decided to close the issue rather than fix it:
TODO: Document in user manual the Widget form as an example with instruction on how to use the various controls etc
- "Anatomy of a AyaNova Form"
TODO: Server needs to do widget validation 666.66 dollar amount test rules not only in debug mode so can test when put up to the devops server
- Test code is in widgetbiz.cs around line 445, but do we need it? Maybe just find a proper server error that can be made to happen naturally?
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 - 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
#locale stuff
TODO: LOCALIZATION form
- Dedicated area for localization adjustments
- Going to be a central form for all localization not form by form
- Review the spec doc and the cases regarding this as there are some little touches that were requested and make sense related to search and replace and other things.
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: 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
- whut? Not sure what this is
TODO: Need to do all outstanding edit form stuff next
### RETEST ALL DEVICES WHEN GET TO HERE #####
TO TEST:
- above changes block
TODO: TRIAL AND LICENSE KEY / ROCKFISH STUFF
- PLAN IN core-license-key-system.txt on server side
- random notes maybe relevant
- Test when logging in and server is ops only due to license not installed
- Does it work?
- With ops level user?
- Should it go to a specific ops page only due to state?
- So user can remotely fetch key and shit
- Why not have server automatically fetch a trial license if it sees it's unlicensed?
- Does DBID get changed on erase?
- WHAT IT SHOULD DO ACCORDING TO PLAN IN core-license-key-system.txt on server side:
- user installs raven, opens client.
- Client checks if server is licensed, if it isn't then it goes to a license request form in client
- User fills out form and submits.
TODO: GUIDED TOUR
- This is an important feature and at least get a basic one in there for starters and initial release
- This is a replacement for the tutorials and videos in v7 a
- Need to add that auto-pilot thingy or whatever the fuck it is that allows for guided tours in HTML apps
- Specifically it should at least have an ONBOARDING walk through of how to move around, enter data, get help etc. Not feature specific but usage specfic.
- Later I'll add feature specfic tutorials like how to make a workorder etc
MAYBE: AUTO-LOGOUT EXPIRED SESSION?
- planning:
- Moved to maybe in case it's an issue down the road
- first off, is this really an issue?
- No, actually it's kind of useful for keeping on working when a server needs a restart or something
- Only real issue is cached data mismatch so perhaps when detected it should toss cached data forcing a reload
- Or is this really an issue either? things cached are form customization and locale text which in the normal course of things won't change much
- Right now a user can simply close the browser in the middle of a session, re-open it any amount of time later and it will just keep working, however it might have outdatd cached data from the server
- What about a time limit after which a session needs to login again just to protect the users from themselves?
- Perhaps it can detect a full page refresh (which is what a restart essentially is) and see how long ago it was last active, maybe the time of the last API call to the server and use that info to force re-login.
- ACTION:
- add code to reliably detect when a user opens the browser or reloads with a session active
- Add code to track last active
- User interacted with server sb good enough
- toss any cached data if it's been more than an hour since the session was last active
FIXES REQUIRED (WTF? Is this still valid stuff ????????????????????????????????????????????????????????????????????????????????????????????????)
- API get code is incorrectly dealing with expired bearer cert, a 401 is returned and it tries to parse the result as if it succeeded when it really should trigger a login process
- Time zone offset mismatch warning needs expansion, it should only prompt a few times (maybe or find a way to deal with this) and it should offer to change it at the server automatically
- Localize time zone mismatch warning
- Don't like popup messages, would rather see a notification icon and be part of that unless it's super critical
- Implement a toaster or some similar notification
Make a basic crud form with all the fields necessary, then iterate over it adding the items below.
- CRUD form for widget:
- Needs to be a main form that is opened via route and parameter so that any part of AyaNova can just navigate to that page and it can be bookmarked.
- Not suitable for a popup form
- This means the list needs to remember where it was at when navigating back to it
Everything needs to work in this form right down to the reports so that once it's done I can move forward confidentally with testing, demo-ing and with cranking out the other forms
- Don't want to solve any problems that should have been solved with this form later as I will inevitably be full on copy and pasting once I get it down and so it needs to be as solid as possible First
- TEST SMALL and LARGE device layout regularly, don't get too far ahead of the testing
- Every type of entry field fully localized properly including numeric, date, time, tags etc
- Client: initialize after login sets locale formats for everything.
- Best to do this useroptions stuff after a form is in place that I can play with at the client and experiment to see what is possible
- How much flexibility do we have to set things like numeric / currency input / display format?
- First it gets useroptions to know what to override or not, then sets defaults based on browser or override settings in central client area for all display/parsing etc
- All numeric and date displays and input in locale format
- numeric inputs need to be set as such so that the number keyboard appears
- And all specialty inputs of course
- Custom fields implemented!
- A printable report
- Even if there is no designer yet for the report and it has to use a manually created report format HTML doc
- Error and validation properly implemented
- broken rule display
- Error reporting overall properly implemented
- ensure error messages that come back from API that start with LT: will be localized correctly before display / logging (may need string interpolation too for some in future, consider that)
- Validation / validation rules
- Vee validate and vuedelate both work tightly with vuetify and v-form
- Vee-validate can be localized
- https://baianat.github.io/vee-validate/guide/rules.html#after
- Dirty check and warning if navigate away.
- Dirty form check and prevent route leave: https://router.vuejs.org/guide/advanced/navigation-guards.html#in-component-guards
- Menu with common options
- File attachments set and get
- Duplicate
- ETC (look it up)
- WIKI PAGE
- Doesn't require docs support as is now changed to a standard file attachment
- This should just be kept in mind as a technique to use if necessary:
- https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3494
- UI:GENERAL:LAYOUT: - All layout, not just workorder needs to be modular and optional sections with simple starting view.
- Calendar form using new vuetify calendar control
- MISC
- Search area seems to take up too much space
- SERVER CHANGE USEROPTIONS SETTINGS NEEDED:
- Best to do this useroptions stuff after a form is in place that I can play with at the client and experiment to see what is possible
- Will need currency symbol, date format, numeric format from user settings at server
- Allow a choice: browser native display format or forced format set in useroptions
- Code the client so it will do either one from a setting fetched off the server for a session
- THESE SETTINGS NEEDED FOR USEROPTIONS
- Use browser TimeZone
- Use this timezoneoffset (already have this)
- Use browser Numeric format
- Override browser with these numeric format settings instead (see below)
- Digit grouping symbol i.e. the , in 1,000,000
- decimalValid symbol i.e. the . in 1.00
- Currency symbol string (may be more than one character in some locales i.e. "Eur")
- negative display format one of these: -1.1, (1.1), 1.1-
- Use browser Datetime format
- Override browser datetime with these settings instead (see below)
- One single date format string? Or one for time, one for date and one for date/time? (see v7)
- Take from day.js (https://github.com/iamkun/dayjs/blob/master/docs/en/API-reference.md#list-of-all-available-formats)
- Do not allow anything other than numeric display, i.e. no January or Saturday so we avoid localization issues
......
- LIST
- Ellipsis submenu with mass ops options and other list wide options appear there
- Print / report
- Show tags in main list as they were added to widget recently
- They come from the api as an array of strings
- Check the rights to the list before it gets the data
- Sort and filter dialog
- Widget list component that works with real data
- paging, sorting, filtering (columns and by tag), items per page
- Single column sorting only
- Filter by popup dialog
- generic dialog that accepts a object specifying column names and types and builds a UI with the options on it
- when applied it saves it as an object that is sent up to the server for each column sorted on in query string
- Server list needs to accept those options and sort accordingly.
- Each item can be edited if they have the rights or viewed etc by opening into crud component
- List should remember where the user was when they go to edit and back again
- What to do if they edit? Refresh the list but keep the same page location?
- something I just forgot as I went to write it and got stuck reading older shit here
- AUTOMATED UI TESTING - I need to institute it now and make tests so I have a template to work off for all future tests
TESTING TODO
Localized input and parsing and validation
- Going to need to handle localized numeric entry formats
- Deal with this once form is in good shape and worth testing with different locales
-----------------
TODO AFTER CLIENT block ABOVE:
ON UPDATE: have an url that opens automatically or a notification and link to one after a new version has been detected just like visual studio does in order to show what is new in this version
ABOUT form - add the user settings such as timezone offset, locale formatting patterns etc, will be useful for troubleshooting
AUTOCOMPLETE
- This article is spot on and I need to implement it like this: http://jeremymikkola.com/posts/2019_03_19_rules_for_autocomplete.html
- Check article responses and comments here for tweaks: https://news.ycombinator.com/item?id=19438826
"THORNY ISSUES" below are needed to be resolved sooner than later
- Maybe an issue maybe not: On field change and lose focus, the save button is not enabled necessarily until the second click
- Can the save button be enabled more quickly after losing focus on the edited field or should I revamp that?
- I can see users making a quick change clicking on save once and it won't save but they think it has.
- Right now you need to click twice on save
- Stage 2 AFTER POSTED TEST ROUND COMPLETED
- Error handling at client (log? display?)
- Notification of some kind (bell / toast)
- Add intro.js somewhere, even if just a quick hello type thing with one single pointer to something on the screen
- Look into: should each component do it's own ajax calls?
- Make a widget component / form to view/list/enter/edit
- Graph / Readonly UI component
- Widget: List, search, edit, localized WIDGET UI components
- Post up another build with the entry form and re-round of testing
- Stage 2.5 TESTING
- Enable some end to end testing and use it going forward all over.
- Stage 3:
- At the end of this phase re-assess and see what needs to be the focus going forward and if anything is amiss
- Plan out the next phase
- UI layout design, how I want to see things, don't re-invent the wheel; v7 isn't perfect but I don't have forever either
- Just remember roles and role based security and that might lead into the UI
- the dashboard can drive a lot because for example a graph or list of workorders could also be where you add a new wo
- Thorny issues:
- Reporting
- Should reports be generated *at* the server then sent back as a pdf or html page or something?
- I'm wondering how it will handle huge datasets, the grids will have sane limits but a report must by necessity report all the user's chosen data
- Notifications from the server
- File upload / download
- Offline abilities?
- TIME TO MARKET TIME TO MARKET TIME TO MARKET
- RELEASE IT, RELEASE IT, RELEASE IT!!!!
- Need a good think about this, time to market is of utmost importance but it would not hurt to see what can be done now or defferred to vNext
- v7 is technically an always online app so there's that.
- Would be nice to maybe be able to do some limited stuff offline
- scope out a scenario or leave for vNext?
- Fill out a workorder that is already up on the phone?
- Parts can't be cached locally, there could be thousands, but maybe labour only is supported?
- Maybe parts can be entered as text when offline for later lookup?
- NOTE: many users want to see some progress on v8 so it's important that the initial shell have some "flash" to it
- Nice transitions
- Some sample charts
- test well on all form factors
- Have examples of a form with all RAVEN required control types enabled
- Use Intro.js to introduce the demo to new users and also to introduce the UI elements and it will be used all over the place!!
- Stage 4:
- Customer demo!!
*********************************************************************************************************************************************************
## TODO...MAYBE??
This is stuff I thought of but is dubiously necessary for the initial release at least or could be polish added later:
TODO: Form dirty indicator on the form and easy to see, maybe the background tinges or something
- Save button kind of is, do we need this?
TODO: Trial mode client should offer alternative logins right on login page and fill in for user to try out
- So a list of user names and a short text of what that user is used for when testing
- User can select and it will prefill in the form
- Obvs when not trial mode then the client doesn't offer it
Reference in New Issue View Git Blame Copy Permalink