admin/raven-client
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
c0fcecb3f8da7ab80d37fdbdd3084fd9206fb2ed
raven-client/ayanova/devdocs/todo.txt
John Cardinal c0fcecb3f8
2020-06-10 13:53:59 +00:00

804 lines
48 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
@@@@@@@@@@@ ROADMAP STAGE 2:
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
=-=-=-=-
WIFI change 5g channel to 52,56,60 and 2g channel to 8
recheck before doing as it seems to vary, maybe someone else's is auto switching
todo: User logs in with default manager account and it's NOT a trial database:
CLIENT UI immediately requires change of password on the spot then logs user out after successful change
todo: ensure dbid on about page
todo: Administration - License
- view current license
- View polling status
- If message in license table then shows it as well
Used to show revocation messages etc
- Verify email address
- View and copy DBID (very important, they will need it to purchase manually)
- Erase all biz data (new route and command needed at back as currently it erases ops data as well I think)
- Request trial license key?
- Have a button that triggers an immediate check for new license at rockfish
- Show last result of license check job?
todo: License testing (I know it's working when these things all pass)
ONBOARDING / BOOTSTRAPPING
NO LICENSE MODE
Client should show the default manager account login info prefilled, no offer of sample trial accounts
If they attempt to login without being *the* manager account and there's no license then server blocks login
Upon login it goes to an onboarding page that iterates through a set of tasks:
1) change password and save it immediately before next step
2) Client checks if there is a registered key for this db via server route:
EMPTY DB AND EXISTING LICENSED KEY IN RF If this DBID is already present in ROCKFISH as *licensed* and FETCHED previously then:
Form displays a message, at top about restoring with link to the manual for restoring db
Rest of form is related to releasing a previously fetched key:
Has a FETCH button on it for forcing a fetch when they have requested it or know it's coming or whatever and below that
A form to fill out to request it be released for re-fetch:
User must fill out form stating reason why and their contact info for verification
The request is emailed to us via Rockfish
We decide to release or not and can contact them etc to handle it
We can release it for refetch and then it's all automatic once daily check (maybe more frequent when unlicensed?) or they can force it
EMPTY DB AND DBID NOT IN ROCKFISH
User gets a form for requesting a trial
- by filling out a form in RAVEN (or using api tool)
- see "trial process" below for details
Form has fetch key button on it to force an immediate fetch
FUTURE: form displays a purchase link they can go to and make purchase inside RF
TRIAL LICENSE MODE
LOGIN: when trial license always takes user to trial form as their home form NOT dashboard
"TRIAL / EVALUATION" PAGE is available ROOT (where logout and widgets are)
Has helpful trial hints, links and tools
Purchase link
Manual link to evaluating?
Guided walkthroughs or links to them?
Erase data
so they can regen new data
or entere their own test data
if(DB empty)
Generate sample data
choose size etc
IF trial license has EXPIRED
Clear message saying trial has expired
Button to erase db and re-request a fresh trial key
Server is automatically checking for updated license periodically
once a day?
User can trigger an immediate license check
User can view and copy DBID
If license expires server goes into READ ONLY mode, all ops valid but only as read only
don't think I actually coded for this
Maybe this isn't the case, maybe ops only is the new license expired?
sure would make people take action faster! :)
On boot of new erased db should
only run in unlicensed mode
Have a unique DBID
only allow ops routes
allow user to request a trial
#################################
todo: server error red box messages have \r\n characters in them
todo: add system to reset password if lost
todo: Administration - Users
is this where roles are set?
role control
mirrors or links to user edit form somehow so admin can also set user options but with added rights like roles etc
todo: Administration - translation
translation page with translation settings
- Translation feedback link in translation page https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3722
- https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1442
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1439
todo: Administration - Attached files
todo: Administration - History
What is this for?
Check if something noted in specs or cases or todo's or comments or help file or something from v7 being expanded / broken out
remove if can't figure it out
todo: Administration - Statistics WTF?
What is this for? Administration related statistics?
Number of records in tables? ?? NO idea
Check if something noted in specs or cases or todo's or comments or help file or something from v7 being expanded / broken out
Remove if can't figure it out
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
todo: Check ops UI rights as limited user
todo: Check administration ui rights as limited user
todo: Backup, probably need to add option "Do not backup automatically"
or something to that effect for scenarios where the built in backup won't be used / won't work
todo: ability to mass tag items from list CLIENT UI
- some kind of generic or copyable light interface for any mass / bulk job?
this will get re-used for other stuff undoubtedly down the road
- also a good way to do an initial implementation of a mass ops UI code
ability to mass rename a tag to something else in all objects
this is bizadmin level page dedicated to this kind of operation, list of objects and mass changes to be made
maybe this is a mass changes feature in general??
Or maybe just targetted to tags and can copy and re-use for something else if needed later
todo: notification
it's time, this is a big deal and it's tied to infrastructure shit so qualifies as an early thing to be done
add CLIENT long polling notification route check
add dummy route for above then flesh out
- Currently there is no UI area for notification display, maybe the settings one there would become that and
there are other ways to do settings already devised see specs / cases
- Notifications for OPS jobs? (Notify me when done kind of thing?)
todo: OPS notification created for failed jobs
also maybe direct immediate email bypassing generator?
Add backup fail to this will stub out for now
This is a bit outdated, lots of decisions already made and worked out in cases / spec docs
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3507
- Need way to acknowledge receipt of long poll info from client to server so that it can be removed or something?
- maybe successfull sending clears it regardless of client?
todo: put sample wiki in docs or maybe in UI as a thing you can click on to insert it into current wiki if empty !!!
or both
Then remove from seeder entirely
todo: WIKI insert image should have extra linefeed before and after because it fails to show the image at all if it follows something like <br> even though it appears to be on the next line
- tl/dr: ensure blank before and after for any url
todo: History - MORE button not showing? Was looking at administrator history for AA import scott
- also, is it showing other types of objects besides Users and Customers? (not seeing wo)
todo: readonly on all forms make sure it's ok, because on customize form I see no save but can edit
- (logged in as bizadminlimited)
todo: when server is in ops only mode the client needs a way to prevent people from opening things that they shouldn't.
for example if a admin logs in they can and should access serverstate page and some other stuff ops related, but all other routes should be locked out
I know the server will send a 404 or something but maybe that needs tweaking to show a proper message at the client or just not show those options or something?
(part of long polling maybe??)
todo: OPEN OBJECT HANDLER
Update it to check if a child type and if so then it calls get ancestor at server search route
Search controller route: ancestor(ayatype, ayaid) returns type and id
todo: found more presets in cases
can I do this date range preset:
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3343
or is it a feature of some kind on it's own
This one: https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1441
todo: router should check rights on each route shouldn't it?
- or should the form check and nav backwards if they don't have the rights
- test: login as subcontractor and direct open widget object
todo: need a role collection control of some kind for things like case 3417.
Control present all or subset of roles for selection, user can select from them like a checkbox dropdown or something.
ideally it binds to a single value and can extract back out of that value bitwise all the correct items in the list checked
This way can bind it to a single bit field value and be efficient FTW$!
TESTING PERF/USABILITY
todo: THIS! At this point, upload to dev server and thoroughly test with devices, it seems a bit slow at times
- Might need to hide attachments until user clicks on something to reveal as it seems odd to fetch every open
todo: careful and thorough PERF tests remotely and local
- https://www.digitalocean.com/community/tutorials/how-to-use-chrome-dev-tools-to-find-performance-bottlenecks?utm_source=DigitalOcean_Newsletter
- https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/reference#rendering
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?
todo: Customer UI pages ability to add analytics tracking codes:
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3574
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: rename v8 export plugin to v8 Migrate
it's more accurate and easier to grasp for people (plus it rhymes)
todo: Investigate Workorder structure and datagrid see case https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3768
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"
=========================================================================================================
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@ ROADMAP STAGE 3
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
This stage is to consolidate the basics and set the final shell form.
todo: notification system?
todo: bottom status panel thing?
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: test error conditions with dev mode off
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: 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: 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
- MRU in dashboard...where? https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3723
- GOOD case here with two great ideas (using "audit log" event log for mru or AS mru and doing it all locally (which I am, no MRU at backend))
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3442
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
#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
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Do reporting here
Componentize of course
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: REPORTING wiki Download, open as pdf, email?
- is this a reporting issue? I think it is, moving to reporting
todo: REPORTING wiki in datalist?
- will need for reports but can't show in a grid, maybe it's available for something but can't be seen or filtered?
- shows in grid as basically a bool like has wiki or not but doesn't show any actual wiki?
- this is only to feed report, no other purpose to it.
todo: Report editor for creating new report accessed from the report any **existing** reports preview form if have the rights.
- or maybe from the report selector dialog box if they have the rights, although would that fuck up navigation process?
- This seems better because, what if they can't preview a report for some reason, then they can never fix it or make a new one?
- NOT like v7 where accessed from the object edit form (this is to keep menu options down to a reasonable number)
- Every list sb reportable case https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3653
- Also search results and history? Can feed from UI level to report component?
- Reporting case with various things pertinent to look over BEFORE starting in on this:
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3451
- https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1849
Instantly print? https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/818
Guy took the time to request it, so have a look think and see if there is a way to do this
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1734
- https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/962
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@ ROADMAP STAGE 5 - FINALIZE ALL NON BIZ OBJECT SPECIFIC FUNCTIONALITY
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
todo: Much of this stage below needs TRIAGING, do that first.
Any real (corebizobject) shit goes to stage 7
todo: MAPPING
getting a *lot* of request about this
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1816
maybe stage 7 or I guess could fake it for now, it's going to be known what will be needed
todo: can I support keycodes for saving in AyaNova and other shit that are the same as in v7 or as much as possible, i.e. ctrl-s to save (or whatever was defined)
What v7 used to support:
f1 - help, case (Keys.Alt | Keys.X) //Close form, alt-w new workorder, alt-m new pm workorder, alt-q new quote, alt-c new client, alt-u new unit, alt-p new part, ctrl-alt-g grid criteria for development,
IMPORTANT / DO THIS: insert date and time (localized) as text anywhere with a key combo
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
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 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
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
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
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@ ROADMAP STAGE 6 - INSTALLER, LICENSING, ROCKFISH SUPPORT FOR RAVEN
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Completely packaged and installable. REady for users to install as a test as I iterate stage 7 below
All the stuff needed for someone to run it as a test without the real objects yet.
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?
Sends errors, server log, suggestions etc, directly to rockfish?
todo: Discourse bootstrapping install
look over, get ideas make case steal ideas profit FTW$
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
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@ ROADMAP STAGE 7 - "REALITY"
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
All in on porting over all the real objects from v7
todo: First of all triage the features to port over in the sanest order so not stubbing too much stuff
Try to get scheduleable stuff early because schedule form will take some time
todo: Schedule form
- This one is big but requires the data to be there so as soon as implement enough things that are scheduleable then do this
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?
I’m really not sure about it.
todo: workorder UI layout stuff (TTM!! Don't re-invent the wheel!)
There's been a lot of ideas about wo floating around and considered, but at the end of the day what I have works so maybe try to meld
into what I have the new concepts and see what comes out. Support a rich wo UI on big screens and scroll around UI on phone maybe.
some notes:
Workorder UI good ideas here: https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3475
Basically (based on RI) it boils down to don't make the user go up to the workorder item level when they can go sideways directly to an alternate child of woitem
i.e. going from parts to labor shouldn't require going up a level
All workorder in one document and just really really tall? (people bitch about RI requiring too many navigation steps to get to shit)
Header and items in one document then bottom in seperate pages?
Is it going to be far easier to code this bitch if I have all the workorder data at hand or..?
How does WBI handle all this because it's kind of the poster child for RAVEN
Workorder is one of those things that may require different views for phone and tablet and laptop etc
Kind of like two views, tiny phone and anything larger
On a PC people will want and expect it to look as much like v7 workorder as possible, maybe that's still a valid layout
just tweaked to work better as a web app a bit but theoretically I could almost duplicate that layout with the tools I have
Consider UI in this as well, will need to decide at least what is visible when
Workorder UI good ideas here: https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3475
How to add items, like new woitem?
send to server get back new object?
lots of biz rules and stuff need to happen, want to minimize load at client
but lots of data back and forth is not ideal
maybe request a woitem and get it back?
what exactly needs to be processed in the wo when items are added / removed?
math / totalling?
simple calcs sb client doable
this will drive what has to happen.
Need to go over all wo features and factor them into this decision properly
The whole idea of a completed section of a wo and stuff, is that dropped due to TTM or still viable?
maybe can pick out the best new features of that which can be integrated into existing design rather than re-inventing the wheel
Here is an overview: https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3412
How best to be able to service LoanUnits on a workorder?
Just make them Units with extra properties exposed if type of loaner?
This seems simplest, but what will it effect?
Hard to make them serviceable if they are an alternate table of source for what's being repaired as that breaks a lot of other code or adds exceptions
Customer is then who exactly because it's fundamental to a lot of wo functionality?
from a biz perspective isn't it like you are your own customer when you service your own equipment that you loan out?
Does Serial field need to be numeric, could it be text instead?
prompted by case 3428 saying that it's hard to deal with constant conversion to text for UI etc
plus, I'm thinking it opens door to textual scheme like appending -A or whatever to a wo.
or, is that a display issue?
Calling something "serial" implies it's unique but it isn't, maybe I should call it "number" instead or "ID" or something?
INFO: did a test workorder with ALL fields filled out heavily and one woitem, exported from db entire graph based on detailed report so every line was every item repeated
still only 84kb and it's a lot bigger than any typical wo in v8 would be as it will be far more efficient without having to repeat lines flatly
so I think size of object is a non-issue really from a practical standpoint.
UI
idea: UI reflects tentativeness state of object:
The UI doesn't imply something is done by changing it fully until the save is completed.
This serves two purposes:
1) user knows at a glance what isn't saved yet and will know it's waiting for save clearly, hopefully leading them to save more often,
2) client doesn't need to track invisible shit behind the scenes, can more easily do patch updates right off UI source
e.g.:
if deleted a row in parts, that row doesn't disappear but rather shows crossed out, maybe grayed out but still there until save to indicate it's tentative status
if added a row, shows green or something or bold or asterisk, (can style with css based on state) until saved
problems:
how to handle regular fields that are changed (that's a lot of field data to track for changes)?
Maybe client keeps a virgin copy of the original wo for comparison
periodically does a compare and flags differences on updates?
(this would also help to serve as an Undo maybe?)
todo: Documentation
Need to think this through carefully
Need to get the critical bits in for onboarding and importing so people can get going
Most important stuff is anything non-obvious
Seems pointless to have one doc per form that just says "The name field is the name and must be unique"
maybe have that kind of stuff in the form basics and then have a doc per OBJECT instead with anything unique or interesting about the object
(and each object form has a link to formbasics so can link to the object form from UI and they get both)
Parts of it can be done post-release for sure
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@ ROADMAP STAGE 8 - PLUGINS
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Plan the order of criticality for plugins
based on sales, how many subscribed now
which ones are porting and which are not
Implement in order or priority
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@ ROADMAP STAGE 9 - RELEASE
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Assuming has passed all testing
Plan pricing and sales strategy
What to do with licenses for v7 people
Do I need another payment processor?
@@@@@@@@@@@@@@@ ROADMAP STAGE 10 - 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
@@@@@@@@@@@@@@@ ROADMAP STAGE 11 - RELEASE SELF SERVE / HOSTING
Fall of 2020 hopefully
links on website for sign up
marketing can begin in earnest
Reference in New Issue View Git Blame Copy Permalink