diff --git a/ayanova/devdocs/todo.txt b/ayanova/devdocs/todo.txt index 6c59dbbd..7d88974a 100644 --- a/ayanova/devdocs/todo.txt +++ b/ayanova/devdocs/todo.txt @@ -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