This commit is contained in:
2020-06-25 23:34:49 +00:00
parent d14f1d9579
commit 435b0ad08f

View File

@@ -3,18 +3,11 @@
PRIORITY - ALWAYS Lowest level stuff first, i.e. TODO at server, api route changes etc then back here in order lowest level first as affects the most stuff exponentially so best to do it early
=-=-=-=-
todo: help links for User, Users, Translations, Translation
todo: set network speed in dev console of firefox to regular 2g then go through all forms and confirm all still works as this will expose any await issues
todo: concurrency violation tests, so far I don't think I've *ever* tested that from the client itself
todo: Administration - Attached files manager
todo: consider moving canDuplicate etc from a "computed" property into methods (just drag and drop)
in fact, look for all computed and consider them carefully because computed seems to be bullshit
replicate v7
look for cases related to this
check specs
todo: Administration - History
What is this for?
@@ -30,8 +23,16 @@ todo: Administration - Statistics WTF?
todo: Administration - Account
Down the road will need an Account page for seeing their account status in rental SAAS situation
Nothing to do here, it's an obvious one, just delete this later, it's to percolate in brain a bit
maybe under license
todo: set network speed in dev console of firefox to regular 2g then go through all forms and confirm all still works as this will expose any await issues
todo: consider moving canDuplicate etc from a "computed" property into methods (just drag and drop)
in fact, look for all computed and consider them carefully because computed seems to be bullshit
todo: concurrency violation tests, so far I don't think I've *ever* tested that from the client itself
todo: Check ops UI rights as limited user
todo: Check administration ui rights as limited user
@@ -117,12 +118,16 @@ todo: keyboard usage test:
- https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3481
todo: Login form customizable for logo etc?
- https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3592
- https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1849
- possibly other cases?
- Still on the fence with this one, I mean why should we give up our branding, on the other hand if people MUST have it maybe a co-logo
Why exactly DO people HAVE to have it? So they can pretend they made it?
if they think their customers would be confused maybe all it needs is the company name predominently on it?
Seems weird to give up our branding and logo in the only place it's actually displayed beyond our marketing materials
Give this a serious thought because it seems like we might be being shitty to ourselves if we support this
todo: Customer UI pages ability to add analytics tracking codes:
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3574
@@ -157,6 +162,9 @@ todo: INSTALLER
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
This stage is to consolidate the basics and set the final shell form.
A lot of it might be rundundent
todo: Go through all cases, just glance over them and make sure nothing was missed that impacts the basic shell stuff before I get into the real world objects
todo: notification system?
todo: bottom status panel thing?
@@ -210,11 +218,6 @@ todo: INVESTIGATE - DO I need to institute a back button? (in APP MODE?? install
todo: DASHBOARD
- Need to cement what is in there, some ideas are MRU
- these cases:
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/2024
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1974
todo: MRU
@@ -229,43 +232,35 @@ todo: INVESTIGATE - Dark mode / theming (dark with a half moon icon)
- 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
#translation stuff
todo: translation form
- Dedicated area for translation adjustments
- Going to be a central form for all translation 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: translation cjkindex, no way to set this value currently
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 translation.
translation 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 translation 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
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@ ROADMAP STAGE 4 - REPORTING
@@@@@@@@@@@@@@@ ROADMAP STAGE 4 - REPORTING / DASHBOARD / KPI
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Do reporting here
Componentize of course
Do reporting and dashboard here
Read over and maybe develop in parallel a bit here a bit there from client down to server as much of this code will overlap in theory
Reporting and dashboard are tied together in a sense because they both need similar data and likely will need similar controls etc
todo: DASHBOARD
- Joyce
- these cases:
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/2024
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1974
Won't have workorders, will need to test with widgets and users, maybe clients will be ported?
todo: DBDUMP Try to see if dbdump plugin can export reports code behind and basic layout, maybe as HTML, enough info to assist report designer with V8.
Be nice to see field list with translation for equivalent new.Also c# code exported and etc Can then get basic calculated field formulas that way, maybe a new report template with code Brought over as comments in JavaScript code behind for new and rudimentary layout of some kind
todo: REPORTS v8 MIGRATE / EXPORT (CUSTOMIZED NOT STOCK) FROM v7? Try to see if plugin can export any aspect of reports
code behind?
even if just exported as comments in js for the new format just to have the formula's etc
basic layout, maybe as HTML?
anything that would help, even just the name of it and it's existence and a TODO in the middle is better than nothing at all
Any info to assist report designer with V8.
Be nice to see field list with translation for equivalent new.
todo: REPORTING wiki Download, open as pdf, email?
- is this a reporting issue? I think it is, moving to reporting
@@ -310,13 +305,6 @@ todo: can I support keycodes for saving in AyaNova and other shit that are the s
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1514
todo: investigate snippets (via hotkeys?) (I like this idea, don't dismiss it outright, could be v.next though. TTM!)
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1834
todo: AyaScript / Look into MACROS (kind of like this idea, don't dismiss it too quickly, need AyaScript replacement TTM!)
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1833
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1680
todo: back and forward buttons when running without browser controls in application mode?
- wait and see on this one, as it will be likely outside of any particular form so not something to be baked in early necessarily
@@ -327,228 +315,25 @@ todo: GUIDED TOUR
- 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
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: clickable urls
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1738
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 translation 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
- Translate time zone mismatch warning (PROBABLY NOT NOW)
- 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 translated properly including numeric, date, time, tags etc
- Client: initialize after login sets translation 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 I 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 translation 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 translated 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 translated
- 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 translations 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 I avoid translation 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
translated input and parsing and validation
- Going to need to handle translated numeric entry formats
- Deal with this once form is in good shape and worth testing with different translations
-----------------
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
TODO: ON UPDATE TO NEW version
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
maybe ideally it opens to a new document page "whats new in version x.xx"
this way no need to go beyond the local server or hit our site unnecessarily
ABOUT form - add the user settings such as timezone offset, translation formatting patterns etc, will be useful for troubleshooting
"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, translated 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 I 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
todo: Suggestion box feature
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1323
@@ -562,7 +347,9 @@ todo: Suggestion box feature
Some kind of expiring license so they can't just keep using it as fucked as it may be some might do that
I want short targetted testing only, not someone downloading and trying it out a month later, that's useless for us
This needs to be focused on what I need to get from people about testing
BETA MODE Feedback form?
todo: Suggestion box: BETA MODE Feedback form?
There is a suggestion box case here somehwere
Sends errors, server log, suggestions etc, directly to rockfish?
todo: Discourse bootstrapping install
@@ -570,24 +357,6 @@ todo: Discourse bootstrapping install
https://github.com/discourse/discourse/blob/master/docs/INSTALL-cloud.md
//here is their standalone config yml definition for DOCKER
https://github.com/discourse/discourse_docker/blob/master/samples/standalone.yml
todo: TRIAL AND LICENSE KEY / ROCKFISH STUFF
- Plan ONBOARDING here
- PLAN and implement 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.
- Trial containerized for easy testing / online testing https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1784
@@ -605,26 +374,6 @@ todo: Schedule form
todo: can beta test at this point
post installer, enlist trial users get feedback, don't get too down when they shit all over it as they will undoubtedly :)
todo: CASE 3780 what's going in the dashboard?
https://www.smartsheet.com/essential-guide-defining-business-dashboard-metrics
will it be customizable?
maybe it's redundant?
Or should just be quick links to commonly used stuff?
it was originally going to be actual UI stuff pickable from various areas of v8, but that's not happening now
in v7 it's like KPI metrics sort of, maybe it's still that
one user asked if it could be "simplified" / customized, I think they just don't want it maybe
"More Simplified View for users or customization of the dashboard of each user."
More Simplified View for users or customization of the dashboard of each user.
[no case but made a note in todo]
update:
"More Simplified View for users or customization of the dashboard of each user."
The V8 dashboard design has not been set yet they are considering everything from removing it entirely to expanding it but haven't come to any conclusions yet.
What would you like to see in there, what would be useful?
>>>> I suppose it could just be removed. It may be difficult to give a snapshot with information that would be pertinent to all of the different types of companies that could use your software.
If it is possible to customize the metrics that you see there somehow or make your own calendar or graphs that can be set by the user, I would like that.
Or maybe just the company logo and some basic information set by an administrator like a homepage for a website. A company wiki with helpful documents?
Im really not sure about it.
todo: workorder UI layout stuff (TTM!! Don't re-invent the wheel!)
@@ -709,6 +458,14 @@ todo: Documentation
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Plan the order of criticality for plugins
ACCOUNTING is obviously the first and foremost one and MUST be there for a lot of people to take up
MUST be done in a way to support other alternative accounting apps that are coming around now like freshbooks or whatever it's called that Joyce is using now
probably going to need a "trick" of some kind to interface with desktop accounting
i.e. a local windows app that uses the api and just copy over the qbi code
or a local server that has it's own web interface
or regular raven UI but the accounting section interfaces with a local server for local desktop qbi stuff and
the raven server interfaces with QBOnline for the QBOI stuff
based on sales, how many subscribed now
which ones are porting and which are not
Implement in order or priority
@@ -723,12 +480,14 @@ Assuming has passed all testing
Plan pricing and sales strategy
What to do with licenses for v7 people
Do I need another payment processor?
Yes, fuck yes absolutely
support bitcoin if possible as well
@@@@@@@@@@@@@@@ ROADMAP STAGE 10 - HOSTING BACKEND SELF SERVER READINESS
@@@@@@@@@@@@@@@ ROADMAP STAGE 10 - ROCKFISH / HOSTING BACKEND SELF SERVER READINESS
DO server allocation, rockfish revamp to drive this part (or maybe it's an alternate app)
https://blog.digitalocean.com/its-all-about-the-bandwidth-why-many-network-intensive-services-select-digitalocean-as-their-cloud/?utm_medium=email&utm_source=do_newsletter&utm_campaign=04292020
https://www.youtube.com/watch?v=zZVoo5AbANI