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-14 00:59:31 +00:00
parent 5d8abba2b6
commit 5b1675fb41
1 changed files with 64 additions and 261 deletions
Download Patch File Download Diff File Expand all files Collapse all files

325
ayanova/devdocs/todo.txt
View File

@@ -25,25 +25,18 @@ Prioritize anything that stands in the way of beta testing
TODO: NEXT:
Not sure, build installers and post them I guess, and back to list, probably time to face the cases amongst other things and triage the stuff added recently
the testing cases and triage the stuff below added recently with an eye to what is needed for beta specfically adn what is needed for initial release and what should be bumped to v.next (make into case)
report sample stuff limited to report designer roles and etc
TODO IMMINENTLY
- Log the startup folder for AyaNova and provide in all areas where you can view config because user may have trouble locating it on windows
- Can't shut down the server in first boot from client due to no ops ui available, ops sb available even when not licensed possibly?
OUTSTANDING MAJOR AREAS TO BETA
# OUTSTANDING MAJOR AREAS TO BETA
- Features
Reports (stock)
mostly there but issue with ordering and missing some obvious ones like Customer etc that should have at least *something* there (ask joyce, her judgement maybe not useful?)
just the sample feature thing I was thinking of to hide examples with checkbox as example in report template so they only show to report designer roles
TEST MODE
comment out or put in a debug block all
internal static bool AYANOVA_SERVER_TEST_MODE { get; set; }
@@ -51,6 +44,36 @@ OUTSTANDING MAJOR AREAS TO BETA
internal static string AYANOVA_SERVER_TEST_MODE_SEEDLEVEL { get; set; }
trial / seeder system
For beta I don't think this is particularly critical, users will likely jump straight to migration anyway no matter what we tell them to do
docs
see docs section below for beta docs issues
dashboard widgets
Not the highest priority for BETA but there shoudl be at least a couple so that feature can be tested also it shoudl at least replicate v7 stuff
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)
- BETA tester docs on what and how suggested to test
# 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
- onboarding process for v7 users guide to migration and also including licensing and etc which requires figuring out pricing and shit
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
@@ -60,56 +83,9 @@ OUTSTANDING MAJOR AREAS TO BETA
or something along those lines, ideas fuzzy at the moment
maybe it's what is there plus additional Task based ones
maybe the UI drives it because we have specific ideas for that
docs
First up is installation docs
need master installation page that gives overview of Ayanova architecture then links to each type of installation
Second is OPS docs, lots of important and missing stuff particularly backup and restore
Third is administration setup which should be mostly done but go over it and find missing bits that a beta tester will need
Fourth is RESTORE and backup 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
WORKORDER docs page is just a placeholder, needs to be written for BETA or people will not be able to figure out basics
do the workorder and the links that go off of it like basic forms shit etc
CLEANUP, go through each docs page look for swear words, inside info, stuff that shouldn't be there and replace with UNDER CONSTRUCTION instead
dashboard widgets
Not the highest priority for BETA but there shoudl be at least a couple so that feature can be tested also it shoudl at least replicate v7 stuff
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)
- onboarding process for existing users
- BETA tester docs on what and how suggested to test
- Here switch from Alpha to Beta designation
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
qbi - 4alarm can't migrate until this is done
qboi
(if pt, well after release if ever)
??? others??
@@ -170,129 +146,6 @@ Coded by importance
██║██║ ╚████║███████║ ██║ ██║ ██║███████╗███████╗
╚═╝╚═╝ ╚═══╝╚══════╝ ╚═╝ ╚═╝ ╚═╝╚══════╝╚══════╝
Install types:
No install - hosted solution by us (down the road or whatever maybe we offer service to setup on their do account for them)
"SINGLE" single user / standalone / beta test no configuration just install and run
"LAN" install
no postgres included, will prompt if they have it and if not will open url to download and install and exit installer
no dotnet framework included, will detect and if not found will open url to download and exit
starts with windows
"IIS" install
same as LAN install but installs under IIS as a host for ayanova
"EXPERT" install
Just an archive containing ayanova program files and a guide doc
"LINUX DOCKER"
maybe this is assuming a fresh new linux, not an expert install but a guide to get it on digitalocean from scratch
Same as our helloayanova.com docker script but in a TAR archive with instructions to build and use with docker
requires NGINX somewhere, maybe we pull it into the build??
"LINUX BAREMETAL EXPERT"
TAR archive and instructions to use with NGINX like how we do rockfish etc
For people that have existing linux server and want to get it going
"MAC" - unsupported experimental
A MAC build of bare files untested for people to try if they really want to go this route
until we have a mac we can't really support this so we should say unsupported
TODO: linux, keep desktop but roll nginx into LAN install and rename LAN install to SERVER install
Have steps up to local network then steps for outside access under nginx
Might have to include whole process for domain name etc or fuck it on that shit?
we might charge to set that up for people so it won't pay to put half-assed instructions that then cause us support headaches anyway, just enough info to get it working
Maybe just link to the other guides on digitalocean or maybe not, that kind of opens the door to support requests as well for that shit.
ditch green server once I have the install guide completed in case I need to refer to anything on there
Might be interesting to set up more than one server on the same server as a test or fuck it that's getting into hosting later, for now assume dedicated servers for people
Make a full cheat sheet guide for ourselves on how to install with digitalocean for an end user, something that Joyce or I can follow along with to get a server quickly set up
# LINUX BAREMETAL NGINX
Followed normal lan install
Installed NGINX using guide here https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-20-04
basically just
sudo apt install nginx
No need to adjust ufw firewall settings at all as am using digitalocean firewall
replaced default nginx site config file here /etc/nginx/sites-enabled/default
with this configuration for initial testing and no ssl or port 443 is required as certbot with nginx plugin will automatically fix that. Also if needed put www.domain in space after server name:
server {
listen 80;
#server_name green.helloayanova.com;
location / {
proxy_pass http://127.0.0.1:7575;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection keep-alive;
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
confirm it's valid:
nginx -t
restart nginx to take effect
systemctl restart nginx
Navigated to the ip address and it works properly but not ssl yet
Also works with subdomain green.helloayanova.com so dns is active now
LETS ENCRYPT
Install certbot
apt install certbot python3-certbot-nginx
Edit default configuration file, uncomment server name (add www.green.helloayanova.com if had set it up in dns record but forgot to so just using green.helloayanova.com, put it all on same line space delimited)
get certificate hopefully don't break other helloayanova.com domain stuff
sudo certbot --nginx -d green.helloayanova.com
Accept prompts, accept to redirect to https, it will re-write the default config file to properly include the https ports and cert etc
Here's what it produced:
-------
server {
server_name green.helloayanova.com www.green.helloayanova.com;
location / {
proxy_pass http://127.0.0.1:7575;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection keep-alive;
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/green.helloayanova.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/green.helloayanova.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
if ($host = green.helloayanova.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
server_name green.helloayanova.com www.green.helloayanova.com;
return 404; # managed by Certbot
}
-----
Testing it out and works perfectly.
Rewrite these instructions for our own future hosting purposes.
@@ -307,34 +160,39 @@ Rewrite these instructions for our own future hosting purposes.
██████╔╝╚██████╔╝╚██████╗╚██████╔╝██║ ╚═╝ ██║███████╗██║ ╚████║ ██║ ██║ ██║ ██║ ██║╚██████╔╝██║ ╚████║
╚═════╝ ╚═════╝ ╚═════╝ ╚═════╝ ╚═╝ ╚═╝╚══════╝╚═╝ ╚═══╝ ╚═╝ ╚═╝ ╚═╝ ╚═╝ ╚═╝ ╚═════╝ ╚═╝ ╚═══╝
TODO: 1 BETA DOCS:
- installation docs
- OPS docs, lots of important and missing stuff particularly backup and restore
- administration setup which should be mostly done but go over it and find missing bits that a beta tester will need
- MIGRATION docs, there *must* be a migration page and it needs to tie into the installation docs perhaps
- evaluation docs where it explains about trial license and requesting and generating data etc, just the basic process and why to do it that way
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???
- Every form's docs should have a ##Roles section that outlines which roles get access to that form
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
WORKORDER docs page is just a placeholder, needs to be written for BETA or people will not be able to figure out basics
do the workorder and the links that go off of it like basic forms shit etc
CLEANUP, go through each docs page look for swear words, inside info, stuff that shouldn't be there and replace with UNDER CONSTRUCTION instead
- 1: todo: the icon for AyaNova is the old yellow one in the docs, change to the new green one
- 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
███ ███ ██ ██████ ██████ █████ ████████ ███████
████ ████ ██ ██ ██ ██ ██ ██ ██ ██
@@ -342,8 +200,6 @@ useful for us to ref as well, should have done it long time ago.
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██████ ██ ██ ██ ██ ██ ███████
@@ -365,63 +221,6 @@ useful for us to ref as well, should have done it long time ago.
figure out a way to group by tags and also filter to only include tags that contain a string of text
i.e. either run a report that groups by each tag found in *every* record
or, optionally, include a parameter which is a string of text to look for in the tag array and only include in a group if it's got that text somewhere in the tag
async function ayPrepareData(ayData) {
//Group by all tags no filter
ayData.ayReportData = ayGroupByTag(ayData.ayReportData);
//Group by filtered tags that contain 'zone'
//ayData.ayReportData = ayGroupByTag(ayData.ayReportData, 'zone');
return ayData;
}
function ayGroupByTag(reportDataArray, tagContains) {
//array to hold grouped data
const ret = [];
const containsQuery = tagContains != null && tagContains != '';
//iterate through the raw reprot data
for (let i = 0; i < reportDataArray.length; i++) {
//get a reference to each object to save typing
let o = reportDataArray[i];
//don't bother with any that don't have tags at all
if (o.Tags && o.Tags.length) {
//loop through all tags for this record
o.Tags.forEach(t => {//t=each tag
//if not a contains query just process it, if it is a contains query then only process if tag contains tagContains
if (!containsQuery || t.includes(tagContains)) {
let groupObject = ret.find(z => z.group == t);
if (groupObject != undefined) {
//there is already a matching group in the return array so just push this raw report data record into it
groupObject.items.push(o);
//update the count for this group's items
groupObject.count++;
} else {
//No group yet, so start a new one in the ret array and push this raw report data record
ret.push({ group: t, items: [o], count: 1 });
}
}
})
}
}
//Sort based on the group name in a locale aware manner
ret.sort(function (a, b) {
return a.group.localeCompare(b.group);
});
return ret;
}
## CLIENT MISC ITEMS
@@ -603,6 +402,10 @@ todo: 3 Schedule form reporting?
|_____/|______|_| \_\ \/ |______|_| \_\
TODO: 1 Log the startup folder for AyaNova and provide in all areas where you can view config because user may have trouble locating it on windows
Also, log the data folder in case it isn't already so users can see where their data is (should show in log and also in UI)
this will be used for tech support often so be sure it's useful to us
todo: 1 When there is a rendering issue with chromium browser startup the server *must* log that to the server log, right now it just half-ass reports it back to the client only
this is because it was written expecting any error was a template error not a starting chromium error so need to look there in the exception handler
would rather not log report template issues to the server log but anything else structural should be