admin/raven-client
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Browse Source
This commit is contained in:
John Cardinal
2021-12-01 20:32:30 +00:00
parent 8e7a04663f
commit 900fdb141b
1 changed files with 40 additions and 50 deletions
Download Patch File Download Diff File Expand all files Collapse all files

90
ayanova/devdocs/todo.txt
View File

@@ -29,6 +29,11 @@ OUTSTANDING MAJOR AREAS TO BETA
- Features
dashboard widgets
Just enough an no more, this could be endless, come up with a top 5 or something and limit it to that
(this is also a very juicy v.next feature thing too)
Note that it *must* at minimum recreate the v7 dashboard stuff (but nicer and graphical)
personal upcoming events like maybe an "next 5 open work orders I'm scheduled on"
or a widget that is upcoming work orders that are a specific status (maybe, just speculating here)
Installer
Linux
Offer as archive for docker and for bare metal
@@ -42,6 +47,10 @@ OUTSTANDING MAJOR AREAS TO BETA
Reports (stock)
trial / seeder system
do not specify by size but rather scenario
we care about size for load testing but don't want to give impression we think HUGE is just a few 10s of thousands of workorders because it's a db issue at a certain point
Also NO time estimates in the UI, just make sure they are all a reasonable length of time to generate, like no more than 15 minutes or something, ideally less than 5 minutes
This should be coded by *task* rather than object to make life easier when we implement
i.e. a MakeWorkorderItemPartRequest task would go through the rigamarole of making a part request, a PO to fulfil it etc
or something along those lines, ideas fuzzy at the moment
@@ -50,7 +59,7 @@ OUTSTANDING MAJOR AREAS TO BETA
docs
First up is installation docs
need master installation page that gives overview of Ayanova architecture then links to each type of installation
See Global Settings form for format for all feature pages
MOST IMPORTANT is the basic stuff about how to use forms and controls and stuff before getting into actual feature pages
this is because beta testers and users will probably already know about each object so the first thing is to get them going with basic usability docs if prioritizing
@@ -65,6 +74,7 @@ OUTSTANDING MAJOR AREAS TO BETA
- Somewhere document that a login is good for 5 days from moment of login before needing to login again
- onboarding process for existing users
- BETA tester docs on what and how suggested to test
- Here switch from Alpha to Beta designation
@@ -73,19 +83,25 @@ OUTSTANDING MAJOR AREAS TO BETA
OUTSTANDING BEFORE RELEASE
- New website for v8?
- New forums for v8?
- Beta testing completed
this is going to be huge becuase users will find a million bugs and issues with how things work and it will be a big clusterfuck for a while so plan for time and patience
- Here switch from BETA to RC designation, let it soak for a bit before full release
- Plugin / addon replacements implemented and fully tested
qbi
qboi
(if pt, well after release if ever)
??? others??
- Regression tests completed and ready to use *before* release so we can add issues to it as they come up and test reliably
- Rockfish licensing finished up
lots to do there but enough for trial and sales for now in existing is enough
one license redundant route also should be baked into initial release even if it points to same place for now
- Biz decisions
Share it product pages for v8 so can be purchased
pricing
When did we last raise prices? What date? What has been the amount of inflation since that date?
What can the market bear?
@@ -114,55 +130,9 @@ OUTSTANDING BEFORE RELEASE
TRACK:
Customer work order form / view / open???
Customer CSR form has a bunch of todo in the template, WTF?
Dashboard / widgets
Just enough an no more, this could be endless, come up with a top 5 or something and limit it to that
(this is also a very juicy v.next feature thing too)
Note that it *must* at minimum recreate the v7 dashboard stuff (but nicer and graphical)
personal upcoming events like maybe an "next 5 open work orders I'm scheduled on"
or a widget that is upcoming work orders that are a specific status (maybe, just speculating here)
Installer INNO
version with postgres included, version without postgres included
quick trialers / beta testers will want a self contained test on windows scenario with built in pg until they get serious
Some will want an online hosted test
Linux install??
Docker build from something we host?
self hosted repo??
windows docker build??
....
V8Migrate completion
All stock reports (and schedule ones)
Seeder / evaluation system worked out fully and implemented
do not specify by size but rather scenario
we care about size for load testing but don't want to give impression we think HUGE is just a few 10s of thousands of workorders because it's a db issue at a certain point
Also NO time estimates in the UI, just make sure they are all a reasonable length of time to generate, like no more than 15 minutes or something, ideally less than 5 minutes
Load testing
Smoke test for every post release build that I can add problems to as I fix them to avoid regressions
Beta testing
Manual pages docs
Fill out everything as quickly as possible, take text from v7 docs where necessary to speed up process
Better to get a v1 manual out and fix it up later than to leave big empty sections even during beta testing
Extensions to replace current add-on's
QBOI
QBI
(if pt, well after release if ever)
Rockfish / Back end infrastructure (round robin license fetching / mirror license domains / machines)
Biz decisions about pricing, licensing, hosting etc
Release!
Profit!
## CLIENT / SERVER MISC ITEMS THAT CAME UP
## MISC ITEMS THAT CAME UP
Coded by importance
@@ -249,11 +219,31 @@ EXTERNALLY ACCESSIBLE
██║ ██║██║ ██║██║ ██║ ██║██║╚██╔╝██║██╔══╝ ██║╚██╗██║ ██║ ██╔══██║ ██║ ██║██║ ██║██║╚██╗██║
██████╔╝╚██████╔╝╚██████╗╚██████╔╝██║ ╚═╝ ██║███████╗██║ ╚████║ ██║ ██║ ██║ ██║ ██║╚██████╔╝██║ ╚████║
╚═════╝ ╚═════╝ ╚═════╝ ╚═════╝ ╚═╝ ╚═╝╚══════╝╚═╝ ╚═══╝ ╚═╝ ╚═╝ ╚═╝ ╚═╝ ╚═╝ ╚═════╝ ╚═╝ ╚═══╝
- Mirror docs to our site so we can link to a central place for them when doing website and for beta test, installation etc
First up is installation docs
need master installation page that gives overview of Ayanova architecture then links to each type of installation
- BETA TESTER DOCS
Make it part of regular docs, host regular docs somewhere on our site
- Every form's docs should have a ##Roles section that outlines which roles get access to that form
- document config.json in addition to other environment variable docs
See Global Settings form for format for all feature pages
MOST IMPORTANT is the basic stuff about how to use forms and controls and stuff before getting into actual feature pages
this is because beta testers and users will probably already know about each object so the first thing is to get them going with basic usability docs if prioritizing
- Has pertinent cases
- ROLES need a completely full documentation or some way to view what is accessible for what maybe in code in the UI???
There is no clear ROLES guide and we need one for sure. I like the idea of dynamically generated in the UI so we can change it and it's always accurate and
useful for us to ref as well, should have done it long time ago.
- Forms and controls
Every form help page should, at the top have a link to Standard form controls or How to use forms so user can move from any topic to how to use the basic controls etc
I guess in a section outlining the fields and menu options on the form there should be links to "Common menu options" and "Common controls" and common controls should have a link to how to use forms
common controls means Wiki, active, attachments, tags, names and their uniqueness etc
- Somewhere document that a login is good for 5 days from moment of login before needing to login again
## MIGRATION ITEMS
███ ███ ██ ██████ ██████ █████ ████████ ███████