devdocs/specs/admin-settings-business.txt

@@ -0,0 +1,17 @@
+https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3488
+Was all this stuff below, however, will be different in RAVEN
+
+### ADMINISTRATION
+
+- *ONBOARDING / GUIDED SETUP
+
+- GLOBAL SETTINGS
+- REGIONS
+- SECURITY GROUPS
+- USERS
+- CUSTOM FIELDS DESIGN
+- LOCALIZED TEXT DESIGN
+- NOTIFICATION DELIVERIES
+- REPORT TEMPLATES
+- FILES IN DATABASE
+- SCHEDULE MARKERS 

devdocs/specs/admin-settings-system-operations.txt

@@ -0,0 +1 @@
+https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3488

devdocs/specs/authentication.txt

@@ -0,0 +1,3 @@
+Authentication
+
+

devdocs/specs/client-group-deprecated.txt

@@ -0,0 +1,2 @@
+Replace client group with tags, see case 3441, 3373
+

devdocs/specs/client-service-requests.txt

@@ -0,0 +1 @@
+

devdocs/specs/clients.txt

@@ -0,0 +1 @@
+

devdocs/specs/core-attachments.txt

@@ -0,0 +1,6 @@
+# Attachments specifications
+
+## TODO
+
+- Need core dlToken route for not just attachments
+- There should be a notification for ops if a file attachment is physically not found when it has a db record see Attachmentcontroller line 407

devdocs/specs/core-backup-and-restore.txt

@@ -0,0 +1,53 @@
+BACKUP AND RESTORE SPECS
+
+CASES
+
+
+REQUIREMENTS
+
+BACKUP 
+- Backup to independent text format using JSON text files like DB DUMP and Discourse does
+- Backup all attached files (encrypt?)
+- Encrypt the backup file archive or each file (need to determine) so that the backup file can't be read independent of RAVEN
+    - Encryption key needs to be user selectable because we don't want any AyaNova user to be able to restore any other AyaNova users db
+
+- Optionally automatically send the backups to online destinations such as 
+    - AWS web storage
+    - Dropbox
+    - Mailbox if under certain size
+    - Look into whatever apis are available for other online storage services
+- Download backups
+- Backup during closed window where server is not available for anything but read only operations during backup window
+- User configurable backup time 
+- User configurable encryption key in environment variable? If not set then not encrypted?? 
+
+
+
+
+RESTORE
+- Automatically closes api before RESTORE
+- Restore from backup locations can save to? 
+    - Or at least a method to fetch and list those backups to fetch to local?
+- Upload a backup file for restoration
+- Decrypts data during restore process
+    - Must use user provided key and there should be some kind of marker file or something to verify it decrypted properly and is a valid AyaNova backup
+- Restore the attached files (decrypt?)
+- Uses user configurable encryption key
+
+ROLES
+- Ops ful, biz full can 
+    - modify backup configuration
+    - Restore 
+    - Backup
+
+- OpsLImited and biz limited can 
+    - view the backup and restore configuration 
+    - Backup
+
+
+
+    
+
+
+
+

devdocs/specs/core-check-for-updates.txt

@@ -0,0 +1,10 @@
+CHECK AND UPDATE SPECS
+
+REQUIREMENTS
+
+- Must confirm current RAVEN is licensed before checking for updates with a current and valid support and updates license
+    - We don't want people to initiate an update if they aren't eligable
+    - We also don't want Raven to allow it to run if the new code was built after the current support and updates in the license expired
+    - Check internal license
+    - Check externally with Rockfish if licensed
+    - Probably best if it just has an update check route to Rockfish where it feeds license serial number (obfuscated?) to Rockfish so it can see which license it is currently using 

devdocs/specs/core-documentation.txt

@@ -0,0 +1,46 @@
+Documentation
+
+HELP MANUAL POINTS TO CONSIDER 
+
+ONBOARDING
+    - The manual and/or guides and/or built into UI guided help needs to answer all the specific questions people have when onboarding
+        - For example a section for technicians, dispatcher, each business role and then under that answers to basic questions:
+            - How do I see my workorders that are open
+            - How do I see who is where today
+            - How do order inventory
+    - The old manual and guide weren't job and task oriented so it doesn't directly answer questions people have, 
+        it just shows how to use features which isn't the way people approach it when familiarizing themselves.
+
+PRE-SALES
+    - Similar to onboarding but a higher level view, just basically answering the questions "Can it do XXX??"
+    - Perhaps it's the same as onboarding but you have to click through for ever increasing detail so you can abandon once your question is answered 
+
+
+
+
+
+
+- User docs and manual written in Markdown format (commonmark).
+- MKDOCS tool used to generate static html "site" for docs
+- Docs versioned into folders by major/minor version, so different docs for 8.1 and again different for 8.2.  Patch revisions don't change docs.
+- Static docs site incorporated into AyaNova backend so can view the docs for that release inside it directly.
+- Docs written in parallel with development as per agile principles so as soon as a feature is added it's documented as well.
+
+## Markdown for documentation
+- [Commonmark cheat sheat](http://commonmark.org/help/)
+- [Commonmark testing 'dingus'](http://commonmark.org/help/)
+- Convert markdown to other formats with this tool http://pandoc.org/
+    - Useful for standalone docs maybe
+
+- Auto generate a static site from markdown docs with this developer tool: http://www.mkdocs.org/
+- Material theme for MKDOCS https://squidfunk.github.io/mkdocs-material/
+- MKDocs WIKI (themes, solutions to tricky things etc) https://github.com/mkdocs/mkdocs/wiki
+
+** MKDOCS **
+- HOW TO RUN IT: python -m mkdocs serve to run the server, python -m mkdocs build to build the site
+- package is tragically out of date on my debian, have to install manually
+- Already had Python 2.7.13 (mkdocs page says 2.7.2 in it's example but 2.7 is ok)
+- didn't have PIP so have to get that, selected python-pip in synaptic (v9.0.1-2)
+- Installed mkdoc by running pip install mkdoc
+- apparently not in path have to preface command with python like so: python -m mkdocs new ayanova
+- Also installed the Material theme which looks a lot nicer

devdocs/specs/core-email-ops.txt

@@ -0,0 +1,18 @@
+EMAIL OPS SPECS
+
+CASES
+
+
+
+REQUIREMENTS
+
+
+- Supports notifications via generator
+
+- Needs to deliver email 
+    - Plain text, probably not html for now
+    - Attachments are a possibility and should be allowed for
+    - A simple api that can be called by generator and others as necessary
+
+
+- FUTURE: some future features may require reading email as well

devdocs/specs/core-generator.txt

@@ -0,0 +1,110 @@
+GENERATOR SPECS
+
+CASES
+
+
+
+REQUIREMENTS
+
+
+- Is accessible from OPERATIONS endpoint see core-long-running-operations.txt
+
+
+Use db table OPERATIONS queue to submit jobs for generator to handle.
+
+Generator looks in table periodically for work to do and if the criteria matches starts the job by calling out to the submitting code
+    - Generator is only concerned with the job starting and ending and logging, that kind of thing, it does no work on it's own directly
+    - Start date time 
+    - Is api locked and can it run when api is locked
+    - Is job exclusive, i.e. no other jobs while it's running and or api is locked
+    - Updates into a operationstatus table and endpoint that is open when api is locked
+    - Deletes status succeeded operations and their operationstatus entries after 24 hours automatically
+    - Deletes status FAILED operations and their logs after 2 weeks automatically
+    - New jobs cannot be submitted via the rest api when the REST interface is locked but it can be queried to see what is happening
+    - Hands off completed jobs back to submitter for resolution
+        - I.E. if a workorder was generated from a PM then it goes back to the PM and says "DONE THIS JOB" or "FAILED THIS JOB" and the PM code handles resubmitting a new job for next time
+            - This way generator does less and isn't responsible for hairy complex code that is best handled at the source of the job
+
+    - JOB is actually handed off back to the object that submitted it into the db in the first place to do the work     
+        - i.e. generator sees a send notification job for a workorder status change, it is ready to go so it in turn passes the job ID or info back to the workorder-process-notification code to handle and takes back the result
+        - i.e. a workorder may submit a "notify users about status change" job, generator sees it and in turn calls notify users code in workorder which in turn creates new jobs to send each email
+            generator then sees send email jobs and in each case hands them off to the email processor to deal with
+
+    
+
+
+TODO GO THROUGH GENERATOR CASES AND v7 GENERATOR CODE, COMPILE A LIST OF WHAT GENERATOR NEEDS TO DO
+    - Need a list of everything RAVEN generator will need to do
+    - BREAK out into small separate concerns
+    - Make a spec doc for each separate concern (i.e. one for the process loop, one for the LRO stuff, one for the physical delivery etc)
+    
+
+JOBSWEEPER
+    - Need a maintenance job class that handles periodic routine internal maintenance CoreJobManager
+    - Submits and handles or hands off routine jobs
+        - Clean up database (look for orphaned records) CoreJobDBMaintenance
+        - Check for license maybe or check license validity? (had some plan to automatically pull license from rockfish, to accomodate monthly rentals) CoreJobLicenseCheck
+        - Clear out completed jobs CoreJobSweeper
+        - Probably dozens of other things
+
+NOTIFICATION SWEEPER
+    - Maintains notifications tables: cleans out old ones, finds ones that are "stuck", notifies OPS about weirdness if found, removes undeliverable ones, counts retries etc
+
+
+
+RAVEN JOB SEQUENCE OF OPERATIONS
+
+Hypothetical Widget UPdated notification job
+    - Widget UPdated
+        - Calls into notification code in WidgetBiz or JobObject or maybe INotifyObject to see if it should create a notification
+
+  
+
+
+HOW AND WHAT v7 GENERATOR DOES
+
+These functions are called every 5 minutes by Generate in Winform desktop standalone.
+- GenProcessPM.GeneratePMWorkorders();
+- GenProcessDeliveries.DeliverNotifications();
+- GenProcessClientNotifications.DeliverNotifications();
+
+
+GeneratePMWorkorders 
+    - Calls for a list of pm id's of not expired and generate on date in future (for some reason it's just in future, not a specific time range, seems buggy)
+    - Taks the list of id's and passes them to workorder generate from pm which in turn...
+    - Workorder.cs Makes workorders from PM workorders copying pm wo data into service wo data
+    - Workorder.cs After making the service workorder the last bit of code calculates the next pm date and then adjusts the source pm to the next date
+
+DeliverNotifications (techs)
+    - Get a list via notificationlist :
+    // List of notifications formatted for delivery
+	/// and screened to be deliverable
+	/// 
+	/// 
+	/// 
+	/// Loops through all NotifyEvenRecords 
+	/// For pending type events, checks to see if within users selected notification window
+	/// foreach NotifyEventRecord it adds a NotificationListInfo 
+	/// for each open delivery window for each subscriber to that event
+	/// As it Processes each deliverable notification it formats it to users
+	/// locale and preferences for size etc and keeps track of the address and
+	/// delivery type.
+	/// 
+	/// 
+	/// End result is a list ready to deliver.
+	/// As each one is delivered Ok it should be deleted from the NotifyEvent table by the
+	/// delivery Process that uses this list.
+    - Iterate the list and depending on deliver via method required:
+        - SMS (smtp)
+        - SMTP (email)
+        - POPUP
+        - AYANOVA MEMO
+    - Log delivery and remove event  after each item is delivered individually
+
+
+DeliverNotifications (clients)
+    - Gets a list of client notifications that are ready to deliver (they hold the entire message in EML format)
+    - Attempts smtp server connection, if a problem then logs it and optionally, based on global setting, will bail and retry again later, otherwise proceeds through code which in turn deletes each notification it can't deliver
+    - Delivers via smtp, if fail logs failure. Either way deletes the notification so it's gone forever
+
+

devdocs/specs/core-import-v7.txt

@@ -0,0 +1,71 @@
+IMPORT FROM V7 SPECS
+
+CASES
+- https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3503
+
+
+REQUIREMENTS
+
+- LImited area of concern: rather than trying to do all types of import, I'm going to write this as if it's all for v7 only
+    - only when I write the next importer will I see if there are any savings of combining objects, but for now small classes with single responsibility
+- Import v7 data into RAVEN via datadump plugin for v7
+- ROUTE: endpoint to allow upload of v7 datadump zip file .
+- ROUTE: endpoint to allow delete of uploaded datadump file.
+- ROUTE: endpoint to Show list of datadump files uploaded.
+- ROUTE: endpoint to trigger non-selective import of specified datadump file (import all)
+
+- FUTURE - ROUTE: endpoint to download a picklist collection of objects found in dump suitable for user to then select specific objects (or type of objects) to import 
+- FUTURE - ROUTE: endpoint to trigger selective import from an uploaded datadump file 
+    - future thing if required because user always has option of editing zip file and removing what is not required to be imported
+    - Supports specifying what to import so can just pick clients or something.
+        - Pick by name of folder I guess within zip since each object type is in it's own folder
+
+        
+
+- IMPORT 
+    - user selects all or collection of folders to import from zip
+        - User is returned a jobid that the client can use to display the activity log
+    - Importer opens the archive file and iterates the folders
+    - Each type of object has a corresponding biz object that handles importing that type
+        - So, for example, each client json is handed off to a corresponding ClientBiz for import
+        - Importer updates the opslog as it's doing the import with summary information (3 clients imported successfully etc)
+- Should close api while it's doing the import.
+- Datadump files should be in backup files folder
+
+
+ROLES
+- Ops ful, biz full can submit jobs
+- OpsLImited and biz limited can view the jobs (already coded)
+
+
+OBJECTS
+    - [ImportAyaNova7Controller]
+    - [ImportAyaNova7Biz] object to back controller routes, submit job, run job and pass off import to each biz object in turn that implements: 
+    - [IImportAyaNova7Object] interface for each biz object (e.g. ClientBiz) 
+        - Import(AyaTypeAndID,JSONDATAfromimportfile)
+        
+
+    
+
+OPERATION SEQUENCE
+
+The upload / delete / show list of datadump files part is standard api stuff and doesn't need special handling nor locking the server
+Importing   
+    - Triggered by ops user remotely by selecting datadump file for import
+
+
+
+
+SCHEMA
+
+
+- It would be helpful to have a importmap table that is used temporarily during import to store a map of v7Guid's with their imported RAVEN type and id
+- This way it can be a lookup table to quickly set other imported data, i.e. client id's to match to units being imported.
+IMPORTMAP
+    - ObjectType
+    - ObjectId
+    - v7Guid
+
+
+
+

devdocs/specs/core-license-key-system.txt

@@ -0,0 +1,228 @@
+License key / products
+
+(see marketing-sales-planning.txt specs doc for specific reasoning behind this)
+
+
+CURRENT WORKING STATUS:
+
+2018-06-01
+Rough framework is in place, can fetch a key and can request a key but nothing really connected at the Rockfish end.
+Rockfish will need some ui and other code to handle it
+Putting that off until closer to release as Rockfish will no doubt change before then anyway (also involves a lot of UI work I'm not into right now)
+
+
+
+
+
+PROCESS
+
+LICENSE BOOTSTRAPPING	
+	- RAVEN when boots and inits license will ensure a GUID DBID value  is set in LICENSE TABLE
+		- This is used to match individual databases to licenses and avoid problems with registration names being the only differentiator as in v7
+		- Also this is the new fetch code
+	- RAVEN DB is empty (of biz data) it's license locked and a User MUST EITHER:
+	
+		1) request a trial key for an empty db by filling out a form in RAVEN (or using api tool)	
+			- see "trial process" below for details
+		
+
+		2) Fetch a paid for license
+			- or, in future purchase right inside RAVEN
+			- RAVEN fetches and installs the license and the rest proceeds as normally
+
+TRIAL PROCESS
+==============
+FOR USER: Install RAVEN, boot, go to client endpoint in browser, get prompted for first test of contact with ROCKFISH server, 
+	once that is ok then get prompted to fill out a form to request a trial key or attempt to fetch a key already ready for them
+	User fills out form providing registration name and email address, hits send, told to check email to confirm address then will receive a key after that.
+	They are told they can only request a new trial by erasing all the data first
+
+FOR CODE:
+	- RAVEN user requests a trial key for an empty db by filling out a form in RAVEN (or using api tool)	
+		- registration name, email address are required fields
+		- This request is stored in the db because it may need to be re-sent later on subsequent erasure of biz data
+		- RAVEN makes and stores internally into a new DB a DBID value which uniquely identifies *THAT* database installation	
+		- RAVEN transmits the request details (with dbid value) to ROCKFISH 
+		- RAVEN starts a repeating job that will periodically check the ROCKFISH server for a license response
+	- ROCKFISH validates the request by verifying the email address provided is (is still) valid and by getting our approval after that.
+		- Verifies email by sending an email and waiting for a response to verify the email is valid
+		- If the email is valid then it creates a trial request record for us to view and approve or not approve with cause entered as text
+			- This part we might automate in future but for now it's a good "fuse"
+		- The DBID value is associated permanently with a site in ROCKFISH 
+	- We get a notification of a request sitting in ROCKFISH and we approve it or not
+		- IF APPROVED:
+			- ROCKFISH generates (or looks up if repeat) a customer record, flags it as a trial type customer with a created date (for later GDPR removal or turning into a real customer record)
+			- (ROCKFSIH UI needs a grouping for trial customers for main customer list)
+			- ROCKFISH stores the DBID value in the SITE record
+			- ROCKFISH generates a valid TRIAL license DBID code is the temporary fetch code.  
+			- ROCKFISH Ultimately should do this automatically unless we specifically flag something
+		- IF NOT APPROVED 
+			- ROCKFISH creates a not approved type of license with the fetch code
+			- ROCKFISH sends and email to the user explaining that it's a fail and why
+	- RAVEN knows a request has been sent and has a license job that checks to see if a license is available periodically 
+		- ROCKFISH returns a "no-op" type response if there is no license
+		- ROCKFISH returns a "FAIL" type response if there is a fail with reason code to display to user
+			- RAVEN CANCELS the check for license job and removes the request
+		- ROCKFISH returns a license key when available under the dbid fetch code
+			- ROCKFISH tags the license as "FETCHED" = true so it can't be fetched twice
+			- RAVEN CANCELS the check for license job and attempts to install the key in normal process and initialize
+
+
+PURCHASE PROCESS 
+================
+
+
+FOR USER:
+Assuming ShareIt system still in place:
+Customer makes a purchase, (possibly through RAVEN in which case the DBID is sent with the url to ShareIt to be filled into the purchase page automatically)
+Customer enters their DBID as instructed into a box on the purchase page.  The order is not valid without it and it's a required field.
+customer can easily copy their DB ID from within RAVEN 
+
+We get the order and it gets transferred to ROCKFISH, license key is generated and an automated email notification is sent to user instructing that the license is ready for "pickup".
+User (who is OPS full or limited or BIZ full) goes into the license page in RAVEN UI and selects "Check for new license" at which point the server does the check passing the GUID along with the check, if new license then it installs and inits and informs user.
+If it's a fail for some reason informs user and no change to current license.
+
+
+FOR CODE:
+
+- RAVEN needs a DBID route in licensing controller to return the DBID available to OPS full or read only OR BIZ full rights only.
+- ROCKFISH needs a way to send a license key email to the customer automatically upon generation
+- ROCKFISH needs a new key generation page with the new options on it
+
+
+RENEWAL PROCESS
+===============
+
+FOR USER:
+If perpetual: They get a renewal upcoming notice if yearly (!=ServiceMode) from ROCKFISH so they can update payment info or cancel, RAVEN will start a license check job immediately before expiry
+If Service: they do nothing, it's understood that it will start to check automatically for a new key around the time of expiry of the old key until it receives a CANCELLED response or a key or a FAIL
+
+FOR CODE:
+See below, basically raven will check with rockfish automatically and handle any problems
+
+
+
+"2018" KEY FORMAT
+=================
+- JSON format
+- secured with hash signature, only we can issue valid keys
+- Features, All licenseable items (and some configuration features) are in a single "Features" collection scheduledusers, accounting "Service" (meaning it's rental), "Trial" meaning it's a trial etc.
+	- "ServiceMode" feature which indicates the license is for renting not perpetual so that it can trigger more constant check for new licenses or offer rental specific features and functionality
+	- "TrialMode" feature which indicates it's a trial so a different UI can be presented in some areas with sales links etc
+	- Futureproof, can put anything in there
+- LicenseExpiration date that applies to all features together as a group (no more individual expiry dates)
+	- When the license expires it stops working.  NO read only mode, nothing works except some ops routes to install a new license, that's it
+- MaintenanceExpiration date that applies to support and updates subscription for all features of that license (no individual feature support expiry)
+	- Used by "check for updates" code to see if they are eligable for an update and to auto-update
+- ID This field is critical and should contain the customer ID followed by the license ID, so for example 34-506987
+	- THESE points here below for this item may be invalid if we go with DBID instead, but keeping as seems to make sense
+	- This way we can verify with automated tools the customer requesting without sending an actual name in text and also that they have the latest key or not
+	- RAVEN says "This is my key 34-506987" to ROCKFISH which replies with "Here is a newer key [key]" or "You are up to date" or "Revoked for reason: [non payment]"
+	- (Test keys are all 00-serialid)
+- DBID
+	- This field is the unique DB id (GUID) of the database in use that is first generated by RAVEN when it first boots with an empty db
+	- It is stored in the global settings of the database and is never erased once it is set
+	- It is also used in conjunction with the ID field or possibly on it's own to be the fetch code
+- RegTo: ALL TRIAL KEYS ARE REGISTERED TO SOMEONE NO SUCH THING AS TWO LICENSES IN CIRCULATION WITH THE SAME NAME (i.e. no more "Unregistered trial" meaning it's a trial, every user will have a specific name to test it out)
+	- Rockfish will issue a trial key upon first request from empty db
+	- An empty regto is an invalid key.
+- LicenseFormat
+	- there will be a LicenseFormat version field which will be initially "2018"
+	- This is for future changes to how license is formatted to ease the code burden of detecting that
+	- Old future release versions should work with new licenses but not the reverse
+
+
+
+ROCKFISH CODE
+- FETCHROUTE: Needs a route to automatically check for presence of new licenses from RAVEN, fetch and install them
+	- Will return either a license or an object indicating error or nothing new to return
+
+
+- UI: Needs a whole lot of ui and code to support 
+	- automatic generation of license key from manual and future automated billing
+	- Key stored and served when required with challenge and response system by past key id and customer number maybe
+	automatic billing and renewals but initially generate licenses automatically based on payment info and all that shit
+
+RAVEN CODE
+- Raven if an empty db can send a request for a key to Rockfish with a registered name
+- If db empty on boot set a Guid value in the global settings table that uniquely and permanently identifies that database
+- RAVEN will have two addresses for fetching a license key to different domains so that we can stay up in case of an issue
+	- i.e. it will try rockfish.AyaNova.com first but if it fails then fallback to rockfish.helloayanova.com as secondary
+- If there is an existing key RAVEN will automatically check for a new key close to the expiry period of the old key
+	- If a FAIL is returned it will stop checking and tell the user at which point they must manually start the check after fixing the issue
+	- If a NOOP is returned it will reschedule to check again later
+	- If a CANCELLED is returned then the customer is no longer active and it will never check again unless user manually forces a one time check and the license changes
+	- If a license is returned RAVEN will attempt to install it and also clear the running check job and also clear the CANCELLED status
+
+- RAVEN LICENSE OBJECT / TABLE add a DBID guid column 
+- RAVEN LICENSE OBJECT / TABLE add a LastFetchStatus column corresponding to an enum of FAIL, ACTIVE, CANCELLED
+- RAVEN LICENSE OBJECT / TABLE add a LastFetchMessage column with the last message from the ROCKFISH license route server (so FAIL can be stored and communicated to user)
+
+
+USAGE:
+
+- MUST be able to support monthly billing cycle (automatic license installation or approval so user doesn't have to install key every month)
+	- Rockfish should have a licensed yay or nay or new available route for RAVEN to check periodically and also users can trigger a force check
+- RAVEN checks periodically for new license to fetch in line with billing cycle or expiry cycle.
+	- SAFE fallback if can't contact license server and allow a few misses before something kicks in, but not to allow people to use unlimited by blocking rockfish for example
+
+
+
+
+
+
+
+
+
+PRODUCT LICENSE CHANGES FROM v7
+
+
+Still optional and purchased separately:
+QBOI, QBI, PTI
+
+Possible idea: sold as "Accounting add on" and the user can use one of those of their choice and can switch which means 1 product instead of three which might make keys easier.
+	Possible downside is that we can't track who uses what or what we sell how much of so puts a kink in marketing or planning for deprecation or where to spend 
+	effort, however there are other ways of addressing that.
+
+
+//INCLUDED ADD-ON's
+OLI - INCLUDED / TURNED INTO GENERIC FEATURE IMPORT / EXPORT CONTACTS and SCHEDULE TO ICAL 
+OutLookScheduleExport - INCLUDED / TURNED INTO GENERIC SCHED EXPORT ICAL FORMAT
+Export to xls - Included with RAVEN
+QuickNotification - Included with RAVEN
+ImportExportDuplicate - Included with RAVEN
+RI/WBI/MBI - UNNECESSARY with RAVEN
+
+
+This all brings up the matter then that we might only have two things to license: the number of users and whether there is accounting or not.
+	?? PROS and CONS INLINE WITH RAVEN DESIGN GOALS ??
+
+
+
+
+THOUGHTS
+Raven license key system specs:
+
+
+- CONSIDER supporting non-connected scenario where user is not internet connected
+
+
+
+
+
+
+
+???
+- Don't worry about obfuscation at first (maybe ever, I mean, really)
+- Need automated routine that checks with rockfish to fetch a license automatically when necessary
+	- I.E. it's sub runs out so it starts checking if there is a newer license available and if so fetches it
+- Need an alternative route and UI in Rockfish for RAVEN style license handling
+- Must use a different signing key than AyaNova 7 so we don't expose v8 key stuff, (although, it's just the public part of the key to validate right?)
+=====================================
+
+RESEARCH SOURCES
+- http://www.reprisesoftware.com/blog/2017/08/implement-a-recurring-revenue-license-model/
+- https://www.linkedin.com/pulse/20140819084845-458042-the-change-from-perpetual-to-subscription-based-software-licensing
+- http://software-monetization.tmcnet.com/articles/429528-long-but-rewarding-road-a-recurring-revenue-model.htm
+- How to calculate pricing in a service business: https://www.patriotsoftware.com/accounting/training/blog/how-pricing-services-strategies-models-formula/
+- SAAS pricing models: https://www.cobloom.com/blog/saas-pricing-models

devdocs/specs/core-localization.txt

@@ -0,0 +1,103 @@
+# Localization specifications
+
+
+REQUIREMENTS
+    - Keys are text, human readable and as short as possible
+    - Not numeric ID's for these, strictly textual
+    - values may have substitution tokens in them for certain things
+    - DataDump plugin will export and import any custom locales that did not come with AyaNova 7
+        - Dump needs to check if the "stock" locale has been edited or not before exporting
+        - Only edited ones are exported
+        - For example if someone edited the Spanish locale then it would dump as "Spanish-Custom" (or whatever the word for custom is in that language) so as not to interfere with our stock Built in Spanish in Raven               
+        - The documented renaming (below) will need to be automated during import of v7 stock locales to migrate to the new key values
+    - Two kinds of locales: Stock and Custom.
+        - Stock locales are stored in db and not user editable
+            - STock locale names are whatever the international name for that locale is like "esp" or "fr" etc           
+        - Custom locales are stored in the database and are user customizable
+
+    ROUTES
+    - GET ROUTE that provides a pick list of locales
+
+    - GET ROUTE that returns all key value pairs when requested for a specific locale
+        - This one is for editing purposes or for export to disk
+
+    - GET ROUTE that returns a list of specific key value pairs for a requested locale and specific list of locale keys provided
+        - This one is for day to day ops and will be called on any client opening a new area of UI they have not previously opened
+   
+    - PUT ROUTE that accepts a list of key value pairs and a specific locale and updates the current values in db from the provided list
+        - if locale name key provided is one of our stock ones then it errors out as you can't change the stock locales
+        - if locale doesn't exist in db errors out
+        - biz full rights only 
+
+    - POST ROUTE that creates a new locale duplicated from an existing locale and copies all the values from the existing locale
+        - Post object {sourceLocale:"English", newLocale:"MyLocale"}
+        - Errors if already exists with that name
+        - Sets it to stock=false so it can be edited
+        - This is also how you rename a locale
+
+    - DELETE ROUTE for deleting any non-stock locale
+        - Can't delete current DB default locale (specfic error)        
+        - Users of that locale will be reset to current DB default locale
+ 
+
+
+ 
+CHANGES MADE TO KEYS FROM v7
+     
+    - Replaced all [.Label.] with [.]
+    - Replaced all ["O.] with ["] this needs to be a case sensitive change!!!
+- Removed duplicate key [WorkorderService.CloseByDate] that resulted from last change of O. (the first one between workorderservice and workorderstatus)
+    - Replaced all [.ToolBar.] with [.]
+    - Replaced all [.Toolbar.] with [.]
+    - Replaced all [.Go.] with [.]
+    - Replaced all [.Command.] with [.]
+- Removed duplicate key created by last operation: [UI.Search] (removed second longer one that refers to database)
+    - Replaced all [.Error.] with [.]
+    - Replaced all [.Object.] with [.]
+    - Replaced all ["UI.] with ["] (and removed exact dupe keys created as a result)
+    - Replaced all [.] with []
+- Removed dupe WorkorderItemOutsideService (removed the one with the longest value)
+    - Replaced all ["AddressAddress"] with ["Address"]
+    - Replaced all ["ContactPhoneContactPhone"] with ["ContactPhone"]
+    - Replaced all ["ContactPhonePhone"] with ["ContactPhone"]
+    - Replaced all ["PurchaseOrderPurchaseOrder"] with ["PurchaseOrder"]
+    - Replaced all ["WorkorderItemMiscExpenseExpense"] with ["WorkorderItemMiscExpense"]
+    - Replaced all ["WorkorderItemTravelTravel"] with ["WorkorderItemTravel"]
+
+Note: still some dupes but...fuck it
+   
+
+
+- TODO: As I code, I will select lt keys as required enter them below
+
+
+
+- TODO: Some of the keys are new and not translated from English, when all is done and the keys that will be carried forward are determined, check for untranslated ones
+    - Use Google translate to get a rough approximation.
+        - A technique to get a good translation would be to try various synonyms out and try to zero in on the commonality in translation to ensure a word is not being completely misunderstood to get a better translation
+        - I.E. if different forms of the phrase result in similar words in the other language then it's probably Gucci
+
+
+CLIENT
+    - Client fetches localized text on an as required basis form by form and caches it locally until cache is invalidated
+    - Cache invalidated by either a timeout or possibly receiving a message from the server.
+    - Open an edit form 
+        - client checks local cache (do I have the values for the list of required keys??)
+            - YES: just use it
+            - NO: Send a list of keys to the server along with the user id that are required for this form and get back the LT, put it in the cache
+                - User id required because someone might edit their locale or the locale name and so it needs to check via the user account what the locale is
+
+This way there is no wasted space at the client caching stuff that will never be used
+
+CHANGES:
+    - If the text is changed at the server then a notification should occur for clients using that local to invalidate their cache
+        - Although, that would be a pretty rare event so...maybe not so much, a logout could clear the cache or a login I guess
+
+
+
+LOCALIZED TEXT KEYS ACTUALLY USED
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
+NewKeyValue, OldKeyValue
+------------------------
+
+HelpLicense, UI.Help.License

devdocs/specs/core-log-business.txt

@@ -0,0 +1,29 @@
+Business history log
+
+FROM CASE 79
+
+A central event log used to track changes to business objects and events of significance in AyaNova.
+
+Auto prunes (can be set)
+
+Has some sort of checksum or verification so we can tell it wasn't fucked with
+
+Consumed by various widgets for record history purposes
+Each object defines it's own set of event id's of significance (int enum) in addition to some events common to all objects: 
+
+1=created
+2=modified
+3=deleted
+
+
+
+EVENT LOG DB SCHEMA
+------------------------------------
+AYTYPE (object type int), 
+AYID (object id),
+AYEVENT (event of interest type int defined in object), 
+TIMESTAMP (unix epoch), 
+USERID,
+TEXTRA (text field to identify stuff that can't be retrieved from source object, i.e. deleted record name) 
+
+

devdocs/specs/core-log-security.txt

@@ -0,0 +1,14 @@
+Security history log
+
+FROM CASE 1998
+
+
+A central event log used to track security related events of significance in AyaNova.
+
+- Authentication events (login, logoff)
+- User creation / deletion
+- User role changes
+
+
+Auto prunes (can be set)
+Has some sort of checksum or verification so we can tell it wasn't fucked with

devdocs/specs/core-long-running-operations.txt

@@ -0,0 +1,76 @@
+JOBS / LONG RUNNING OPERATIONS SPECS
+
+
+
+CASES
+
+
+
+REQUIREMENTS
+
+- An endpoint to view jobs in the table
+- An endpoint to view logs of jobs
+- A db schema (see below)
+- biz object callable from other biz objects with following functionality
+    - Submit jobs
+    - Remove jobs
+        - Remove all jobs for object type and id (called when deleting an object)
+    - Update status of jobs
+    - Log ops of jobs
+
+
+
+- OPERATIONS endpoint:
+    - GET JOB LIST Check a list of jobs (with rights to do so). Works even when api is locked.
+        -  GET /operations returns list of jobs sorted by lastActionDateTime or createdDateTime via query parameter
+            - {
+                "jobid":"1234",
+                "createdDateTime": "2015-06-19T12-01-03.45Z",
+                "lastActionDateTime": "2015-06-19T12-01-03.45Z",    //<----determined from log, not stored in AOPSJOB           
+                "name":"Send notifications | Import data | Backup | Restore",
+                "exclusive":"true/false",
+                "status": "sleeping | notstarted | running | succeeded | failed",
+                "log":"/operations/log/1234"
+                }
+
+- ROUTE: "OPERATIONS" endpoint to get log of long running operation /operations/log/1234
+    -    [
+            {
+                 "DateTime": "2015-06-19T12-01-03.45Z",
+                 "Entry": "Imported 4 clients, 3 were duplicates and ignored" 
+            },
+             {
+                 "DateTime": "2015-06-19T12-02-03.45Z",                 
+                 "FAILED to import 5 workorders - data format invalid"
+            },
+             {
+                "DateTime": "2015-06-19T12-04-03.45Z",                 
+                "Operation completed with errors"
+            }
+        ]
+
+- FUTURE: delete jobs that have not started yet
+- FUTURE: cancel jobs and cancellation token
+
+
+
+SCHEMA
+=-=-=-=
+
+AOPSJOB
+    - jobid long NOT NULL INDEXED UNIQUE (initially I'll use linux epoch when job created, used to tag logs etc, but keeping this open for a change later)
+    - OwnerId NOT NULL
+    - Created  NOT NULL
+    - Exclusive NOT NULL bool (true=close api and don't run any other jobs, false=process async and keep api open)
+    - StartAfter NOT NULL INDEXED (datetime to start the job, in cases of start now jobs the date will be minvalue)   
+    - jobtype enum int NOT NULL of the jobtype which is an enum of all possible job types (i.e. NotifyClosed)
+    - ObjectId NULL source of job object id (i.e. workorder id)
+    - ObjectType NULL source of job object type (i.e. workorder)
+    - descriptive name text NOT NULL for display in UI only, isn't filtered    
+    - jobstatus enum int NOT NULL type (one of  "sleeping | notstarted | running | succeeded | failed")   
+    - jobinfo text NULL (json string of extra info required for job, maybe the name of an import file or who knows what, anything really can be put in here as long as it's shortish)
+
+AOPSJOBLOG
+    - jobid long not null
+    - created not null (indexed?  Will be ordered by this a lot but it's the natural order...no?)
+    - statustext NOT NULL

devdocs/specs/core-notification.txt

@@ -0,0 +1,40 @@
+# Notification specifications
+
+
+SCRATCHPAD IDEAS
+=-=-=-=-=-=-=-=-=-
+Hypothetical sequence of operations for designing raven notification and tie into jobs and processor
+
+WidgetStatusChange notification
+	- OnChange event triggered in [WIDGETBIZ] with before and after state of widget in question (immediately after save or delete or whatever is of interest)	
+		- OnChange processor See if any users are subscribed to this event [CENTRAL_NOTIFICATION_CLASS THIS MUST BE SUPER EFFICIENT AS IT WILL BE HAMMERED] (events of interest / core central event bus handler of some kind??)
+			- CENTRAL_NOTIFICATION_CLASS event of interest should cache in memory events of interest and trigger cache invalidation by [EVENT_OF_INTEREST_CLASS] subscription change
+		- If no then bail out early
+		- If yes then compares the before and after state of the widget and the given list of events of interest and processes notifications in turn
+			- Create a notification event in a table of pending notification events [CENTRAL_NOTIFICATION_CLASS]
+				- See v7 schema for ideas
+
+Deliver notifications
+	- Job triggers and HandleJob is called on [CENTRAL_NOTIFICATION_CLASS] which in turn checks if any events ready to Deliver
+		- Hands off NOTIFY_EVENT to deliver one at a time to a [NOTIFICATION_DELIVERY_CLASS] which in turn calls each [NOTIFICATION_DELIVERY_DELIVERY_TYPE-SMPT/POPUP/WHATEVER]
+
+
+Maintenance
+	- [CoreJobNotificationSweeper class] maintains the notifications tables see generator spec for thoughts
+
+
+
+
+
+
+
+
+
+MISC
+=-=-
+
+- NOTIFICATION SUBSCRIPTIONS
+- NOTIFICATION DELIVERIES (user or all if manager account)
+
+- What is "Slack"?
+	- should we tie into it for notifications?

devdocs/specs/core-ops-metrics.txt

@@ -0,0 +1,62 @@
+SYSOPS METRICS / HEALTH CHECKS
+
+
+
+
+Right now as of May 7th 2018 here are the remaining outstanding issues for metrics:
+
+TODO OUTSTANDING ISSUES 
+
+1) Need to make my own dashboard for non endpoint stats for Graphana.  Actually a dashboard that covers all AyaNova would be good
+https://www.influxdata.com/blog/how-to-use-grafana-with-influxdb-to-monitor-time-series-data/
+2) Save the dashboard as JSON text for the manual 
+3) See about making my own Grafana / INfluxdb container and include it in compose.yml for AyaNova server so can deploy it easily (with my own panels pre-built)
+4) DOCUMENT
+5) Skim below and see if I have covered it all.
+
+
+
+
+
+OLD OLD OLD OLD
+This is old stuff I was using during research and initial implementation some of it may still be relevant later
+=-=-=-=-=-=-=-=-=-
+
+APRIL 26 2018 - DID SOME RESEARCH, THIS IS ACTUALLY A VERY COMPLEX TOPIC AND BEST HANDLED WITH A 3RD PARTY TOOL
+- There is an open source metrics tool and an open source db it can work with the is a time series data store (influxdb, elasticsearch) designed for exactly this scenario
+- Influxdb has a docker container available
+- Shitty thing is I would need some of this information for support purposes built in, not requiring some fancy 3rd party tools which are very cool for a large setup,
+but a small one man show doesn't require that.
+- Perhaps RAVEN can have a big corporate edition that is all intended to be containerized and comes with influxdb and preconfigured with metrics on.
+- It handles both metrics and "HEALTH CHECK" issues in one package
+
+- I'm not sure if this is a v1.0 feature, though it would help in development to see what's what route writes
+- If it can be an optional thing that can be turned on then that would be ideal
+- https://al-hardy.blog/2017/04/28/asp-net-core-monitoring-with-influxdb-grafana/
+- https://www.app-metrics.io/
+
+
+
+Ops Metrics
+  
+    - CASE 3502 Add metrics
+    - CASE 3502 Metric: record count in each table or at least major ones as a snapshot metric so can compare month to month.
+    - CASE 3497 ACTIVE user count - Log user login, last login and login per X period
+    - CASE 3499 "Slow" I want to know if anything is slow, not what the user says but what the code determines
+
+    
+
+
+    - some kind of internal metrics to track changes over time in operations with thresholds to trigger logs maybe?
+    - Has to be super fast, maybe an internal counter / cache in memory and a periodic job that writes it out to DB, i.e. don't write to db metrics on every get operation etc
+    - Average response time?
+    - Busyness / unique logins or tokens in use?  A way to see how many distinct users are connecting over a period of time so we know how utilized it is?
+    - Utilization?
+    - Areas / routes used in AyaNova and how often / frequently they are used (we could use this for feature utilization)
+    - CPU peak usage snapshot
+    - Disk space change over time snapshots
+
+
+    HEALTH CHECKS
+    - Comes with appmetrics:
+    - https://al-hardy.blog/2017/04/17/asp-net-core-health-checking/

devdocs/specs/core-ops-support-info-log.txt

@@ -0,0 +1,83 @@
+SYSOPS HEALTH CHECK / METRICS
+
+OK, considered this and a log is a log and all logs are relevant to sysops people so I'm going to treat all logging the same regardless and make an effort to ensure each log entry
+is tagged with the relevant class name
+
+CRITICAL ISSUES
+- Check for critical issues in a health check periodic job which also logs and metrics
+- Critical issues should be logged first then sent via notification for system operators if subscribed
+- 
+
+METRICS
+- metrics should be gathered in DB and reported on via UI for ops users and potentially in other formats down the road
+
+
+
+TODO LIST OF THINGS CODED THAT NEED TO BE LOGGED
+- Items in code tagged with this: 
+    -  //TODO: core-log-sysop
+- Generator failures
+- IJobBiz derived objects failures
+
+- configuration changes ???
+- Install and uninstall feature changes
+- Warnings (low disk space, slowness monitoring, db issues) (during health check JOB??)
+
+
+"HEALTH CHECK" JOB
+- things that need to be metric a sized are commented with //OPSMETRIC
+- Maybe a "health check" job or "checkup" job that periodically asseses things and reports findings
+- works in conjunction with metrics gathered maybe?
+   - Metrics would be a system that for example could get free disk space then get it again a few days later and project ahead to getting low and warning or simple when down to 10% warn or etc
+- Anything we'd like to see from a support point of view would be useful too
+- Go over the research doc to see what was recommended
+- Dig up that guys example project on his blog that he was going to add metrics to.
+- Brainstorm a list of recent support issues and what could be a benefit in dealing with them
+- "Slowness" comes up a lot.
+
+
+Ops Metrics
+    CONFIRMED REQUIRED
+    - Gather in memory and flush to db on a schedule is best
+    - CASE 3562 If found, count of mismatch of attached files in database vs file system
+    - CASE 3523 Log major ops related configuration changes (before and after snapshot)
+    - CASE 3502 Log feature or route or endpoint usage count as a snapshot metric so can compare month to month.
+    - CASE 3502 Log record count in each table or at least major ones as a snapshot metric so can compare month to month.
+    - CASE 3497 ACTIVE user count - Log user login, last login and login per X period
+    - CASE 3499 "Slow" I want to know if anything is slow, not what the user says but what the code determines
+
+    RESEARCH / IDEAS / EXAMPLES
+    - Metric types:
+        - https://www.app-metrics.io/getting-started/metric-types/
+    - Code example that deals with this issue:
+        - https://github.com/AppMetrics/AppMetrics/tree/dev/src/App.Metrics.Core
+    - Need more than one window into the data, for example we need a last few minutes (5?) view so people can see at a glance what is happening NOW
+        - But also need to know what was it historically.  So maybe we need a NOW algorithm but also a HISTORICAL algorithm.
+        - Maybe a sliding scale of recency, so a 5 minute view, a THIS WEEK view and then a month to month view beyond that??
+    - LIBRARIES 
+        - Health check Health Checks give you the ability to monitor the health of your application by writing a small tests which returns either a healthy, degraded or unhealthy result. 
+            - https://www.app-metrics.io/health-checks/
+        - APP METRICS
+            - https://github.com/AppMetrics/AppMetrics
+    - Different types of metrics are Gauges, Counters, Meters, Histograms and Timers and Application Performance Indexes
+    - METRICS of a system:
+        - Network. Network metrics are related to network bandwidth usage.
+        - System. System metrics are related to processor, memory, disk I/O, and network I/O.
+        - Platform. Platform metrics are related to ASP.NET, and the .NET common language runtime (CLR).
+        - Application. Application metrics include custom performance counters "Application Instrumentation".
+        - Service level. Service level metrics are related to your application, such as orders per second and searches per second.
+    - USEFUL INFO HERE FOR SYSTEM METRICS LIKE MEMORY ETC: This document from Microsoft gives generally accepted limits for things like CPU threshold, memory etc in actual percentages
+        - Section "System Resources" here https://msdn.microsoft.com/en-us/library/ff647791.aspx#scalenetchapt15_topic5
+
+    - USEFUL EXAMPLE dashboard for web applications:
+        - https://sandbox.stackify.com/Stacks/WebApps
+
+
+    - some kind of internal metrics to track changes over time in operations with thresholds to trigger logs maybe?
+    - Has to be super fast, maybe an internal counter / cache in memory and a periodic job that writes it out to DB, i.e. don't write to db metrics on every get operation etc
+    - Average response time?
+    - Busyness / unique logins or tokens in use?  A way to see how many distinct users are connecting over a period of time so we know how utilized it is?
+    - Utilization?
+    - Areas / routes used in AyaNova and how often / frequently they are used (we could use this for feature utilization)
+    - CPU peak usage snapshot
+    - Disk space change over time snapshots

devdocs/specs/core-regions.txt

@@ -0,0 +1,27 @@
+REGION SPECS
+
+
+
+CASES
+
+REGIONS:CLIENT:NOTIFICATION:GENERAL: - REGION feature changes case
+https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3454
+
+REGIONS:GENERAL: - denormalize region id in each regionalized object
+https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3476
+
+QUOTE:NOTIFICATION:CR: - Notifications for quote creation should be regionalized (or tags?)
+https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3564
+
+
+
+
+REQUIREMENTS
+
+
+Definitive decision on regions:
+Regions will be deprecated as a feature entirely, no region feature will be in RAVEN / v8.
+Old data will import regions as tags, first the region will be imported as a tag then anything that is imported of that region will be tagged with that region.
+Notifications will work via tags instead, users will be able to filter a notification to anything tagged with that tag.
+Essentially being able to filter out a user from seeing data outside their region is not going to be a feature going forward.
+Roles will be the primary way to restrict what users see and various filters by tag for certain ops like notification etc.

devdocs/specs/core-reporting.txt

@@ -0,0 +1,11 @@
+REPORTING SPECS
+
+CASES
+
+
+
+REQUIREMENTS
+
+- All v7 reports ported to RAVEN
+    - ALL Fields even the ones that don't show on the report but are available for adding to a report in the editor need to be available
+

devdocs/specs/core-roles.txt

@@ -0,0 +1,72 @@
+# Roles specifications
+
+From case https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1809
+
+RAVEN will replace security rights system of v7 with a role based system instead
+I'm using an int flags enum which means a maximum of 32 possible roles unless I bump it up to a long but don't really want to as this number will be thrown around the api a lot
+
+
+
+TODO: Fill this out as I code.
+
+**DELETE RIGHTS***
+If you can modify an object you can delete an object
+
+
+**OWNER LIMITED ROLES**
+Limited roles in some cases can create an object but can only edit or delete objects they created
+
+## ROLES
+
+### None
+No rights, not settable, just for internal usage in code
+
+### BizAdminLimited
+Intended for a business administrator / supervisor who wants to monitor the business, kpi, reporting etc, but doesn't actually get to change anything.
+Suitable for the "big boss" who isn't trusted to make actual day to day decisions but can review anything.
+
+**RIGHTS**
+- Read only access to everything (except OPS stuff)
+- Full access to management reporting, KPI etc, but can't change them substantially, just sort, filter etc.
+
+
+### BizAdminFull
+
+Basically the v7 manager account stuff with full rights to everything other than OpsAdmin stuff.
+
+**RIGHTS**
+- Full access to all AyaNova objects with the sole exception of OPS related stuff
+- Grants roles to other users
+- Licensing
+- Business related configuration settings
+- All management and KPI stuff
+
+### DispatchLimited
+
+### DispatchFull
+
+### InventoryLimited
+
+### InventoryFull
+
+### Accounting
+
+### TechLimited
+
+### TechFull
+
+### SubContractorLimited
+
+### SubContractorFull
+
+### ClientLimited
+
+### ClientFull
+
+### OpsAdminLimited
+
+### OpsAdminFull
+backup, troubleshoot, dashboard of throughput, db administration, all the stuff needed to keep RAVEN up and running and monitor any issues in operations of it, nothing to do with business stuff or actual business data
+
+
+

devdocs/specs/core-search.txt

@@ -0,0 +1,99 @@
+SEARCH SPECS
+
+
+
+CASES
+
+SEARCH: - to have ability to filter by client
+https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1503 
+
+SEARCH:UI:GENERAL: - Search in V8: should be integrated, not a separate form
+https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1672
+
+SEARCH:NEW: - Search dictionary: Auto remove orphaned words
+https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1878
+
+WORKORDER:PARTS:SEARCH:CR:DUPLICATE 3358: - Parts Search on Parts Grid
+https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3310
+
+WORKORDER:PARTS:SEARCH:CR:DUPLICATE 3310: -  Ability to ‘search’ for a part while in a WO or PM
+https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3358
+
+UI:WORKORDER:CR: - Have a search box for clients instead of having to use the slider to find a client
+https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3376
+
+SEARCH:UI:GENERAL: - Be able to search from anywhere in any screen
+https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3459
+
+SEARCH:WORKORDER:PO:QUOTE:PM: - Workorder and other numbered items need to be searchable by their number
+https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3506
+
+
+
+REQUIREMENTS
+
+- USE-CASE: Central text search for any match. Can include tags.  Can specify a type of object.
+- USE-CASE: In-object text search for the typeandid that user is in, e.g. when in Client info form can search on that client. 
+- USE-CASE: Picklist / chooser Search for text of a specific type of object, e.g. find all Clients that contain "squirrel" to drive picklists everywhere
+- USE-CASE: No snippet (excerpts) just name and type.  I think for the initial release I'm *not* going to include snippets with result for several reasons:
+    - Performance: better to get an immediate result than to wait a while to get excerpts that 
+    - Bandwidth: will trigger a lot of probably unneeded Bandwidth and chew up cycles on the db and server 
+    - Can be added later based on feedback (i.e. a lot of bitching)
+    - For performance it would be something that runs *after* the search results are returned, either on demand (user clicks on excert button, or slowly fills in the list async)
+    
+- NAME: in search index include a bool indicating the word is actually part of the name or equivalent of the object, this will make name searches WAAAAYYY easier!!!
+    - in non named objects it's whatever the primary identifier is, i.e. workorder number for a workorder, partnumber for a part
+    - Maybe all objects should have a "name" column in db be it a workorder number or part number just for consistency
+- TAGS: Any search, anywhere, can include tags (internally it will post filter on tags after initial text search or if no text then will just search tags)
+
+- ROLES: Needs to internally be able to filter by CANREAD property of role user is in (e.g. if no rights to read client no clients returned)
+- INDEX VISIBLE ID NUMBERS MUST be searchable so ensure they get put into text search with the regular text.
+- OBJECT ID and/or OBJECT TYPE criteria support (AyaTypeId must be included in search index)
+- PARENT / OPENABLE OBJECT: Objects that are searchable but not openable directly need to contain their parent type and id, this way we can follow a chain to the openeable object if necessary
+    - This is in the object, not in the searchkey as it would be inefficient
+    - Need parent AyaType as an ENUM ATTRIBUTE in the AyaType table for easy traversal
+- CLEANUP: Generator able to cleanup index with no matching word (if possible), index with no matching typeandid
+- CJK INDEX support: same as v7
+- GROUP BY: group by objectype then objectid (then created date?)
+- Coding: break this into separate discrete classes, the old v7 code is very monolithic and in-elegant
+- SAMPLE DATA: Need a huge amount of sample data indexed to load test it
+- INDEXES: play with it and see what works best
+
+
+
+PROPOSED SCHEMA
+asearchdictionary
+    - id (long)
+    - word (nvarchar 255) (indexed?)
+
+asearchkey
+    - id (long)
+    - wordid (fk on asearchdictionary.id)
+    - objectid (long id of source object)
+    - objecttype (AyaType as int of source object)
+    - inname (bool indicates the search word was in the name of the object)
+    
+
+
+
+REFERENCE INFO
+
+V7 Code:
+- Word breaker: AyaBizUtils -> Break starting at line 1976
+- Insert into db: DBUtil.cs -> ProcessKeywords starting at line 423
+- Usage: Client.cs line 2104
+- SearchResultList.cs (whole class, also there is an "ri" version for some reason I forget)
+- V7 DB Schema:
+
+CREATE TABLE [dbo].[ASEARCHDICTIONARY](
+	[AID] [uniqueidentifier] NOT NULL,
+	[AWORD] [nvarchar](255) NOT NULL
+) ON [PRIMARY]
+
+
+CREATE TABLE [dbo].[ASEARCHKEY](
+	[AWORDID] [uniqueidentifier] NOT NULL,
+	[ASOURCEOBJECTID] [uniqueidentifier] NOT NULL,
+	[ASOURCEOBJECTTYPE] [smallint] NOT NULL
+) ON [PRIMARY]
+

devdocs/specs/core-seeds.txt

@@ -0,0 +1,6 @@
+SEEDS
+EXPORT READY (DATA DUMP CODED)
+
+REQUIREMENTS
+See case 3544
+

devdocs/specs/core-server-state.txt

@@ -0,0 +1,30 @@
+SERVER STATE SPECS
+
+REQUIREMENTS
+
+Two parallel paths that can lead to serverstate affecting access to server:
+
+Closed or Open States
+    - If closed all routes are shut to all users with case by case exceptions:
+        - OPS type user exceptions:
+            - Login
+            - View long running jobs because server may be closed due to long running process they need to view for status updates
+            - they can fetch a license key or look at license current state (ONLY IF CLOSED DUE TO LICENSE ISSUE)
+            - View METRICS and log files
+     
+
+- SYSTEM_LOCK 
+    - An independent setting outside of the regular server state that allows RAVEN to internally lock itself when License or lockout related issues like non-payment
+    - Acts as though the server was set to CLOSED so OPS can still go in but doesn't matter what state they set it to because the locked is a parallel in memory internal only setting
+    - All non-ops routes will need to see if closed and server state returns closed both if serverstate is closed or if SYSTEM_LOCK
+
+
+
+
+
+Some scenarios at the server require general users to be LOCKED OUT COMPLETELY but still grant limited access for operations administration, such as:
+    - Biz changes that need all users out such as a re-org of client data or something else business related
+    - Ops changes that need all users out such as upgrades, backup, restore, any mass data change such as import or export
+    - Emergency security issues such as hacking attempt etc
+
+Need a method to inform users that server *WILL* be going down within a set time frame, like 15 minutes (no need to get fancy and make it configurable)

devdocs/specs/core-tags.txt

@@ -0,0 +1,74 @@
+# TAGS specifications
+
+Main case is 3373 https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3373
+
+FORMAT
+=-=-=-
+Copied from stack overflow
+tags ...
+
+    must be no longer than 35 characters
+    spaces are replaced by dashes, no spaces in a tag
+    always converts to lower invariant culture
+    - (probably not this, utf-8 ok: must use the ascii character set a-z 0-9 + # - .)
+
+
+SCHEMA
+=-=-=-
+Two tables:
+
+TAGS
+    - name text not null lowercase only
+    - id bigserial
+    - OwnerId
+    - Created
+TAGMAP
+    - ObjectId
+    - ObjectType
+    - TagId
+    
+INDEXES
+    - Initial index is on the name of the tag as that will be searched for??
+    - After some research I think it's best to just make it, populate it with a great deal of test data and then test query it and see what indexes give the best performance
+    
+
+
+USE-CASES
+Add a tag to an object type and id, start typing and a selection list fills in to select from
+    - Don't allow the same tag more than once
+    - Create a tag if not present (rights?)
+Show tags on an object
+Find any type or specific type items by a set of tags to include and a set of tags to exclude (i.e. has "red, yellow" but not "green")
+Search for text must allow specifying tags to refine
+Reporting will require filtering sources of report data by tags
+
+METHODS REQUIRED IN TAG CONTROLLER
+
+- GET tag text by id
+- GET tag id by tag text 
+- CREATE tag for tagging something
+- REMOVE tag (and all tagmap entities)
+
+
+- GET TAGMAPS LIST (get all object/id entities with this tag)
+- CREATE TAGMAP Apply tag to an object / id 
+- REMOVE TAGMAP remove tag from object/id
+- GET TAGS for object (name id list, main display route)
+
+
+ROLES / RIGHTS
+- Limited roles can tag stuff and remove tags as per their rights to the object type in question but can't make new tags or change existing tags 
+- Full roles can make new tags and can edit or delete existing tags
+    
+
+RETRIEVAL
+
+Will need to query tags as follows:
+
+ObjectType and Id list of tags (most common)
+Objects with one or more tags
+Objects that have a set of tags but do not have another set of tags
+Objects of a certain type but any id that have a certain tag
+
+
+

devdocs/specs/core-testing.txt

@@ -0,0 +1,15 @@
+TESTING
+
+BACK-END
+    - Back end api is currently tested via the api and unit tests that exercise it's routes
+    TODO
+        - Some kind of continual load test of the DO server, try to break it with a lot of tests continually running for a long period of time
+        - A test that simulates multiple simultaneous users at the same time
+
+
+
+FRONT-END
+    TODO    
+        - Integration tests that excercise the front end and ensure things appear where they are supposed to given certain tasks
+        - Ideally it would be able to run a set of business tasks against the UI and confirm at each point like make a rando customer and then a workorder and on 
+        - Something that we can leave running for a long period of time to verify load and no leaks

devdocs/specs/core-trial-evaluation-system.txt

@@ -0,0 +1,36 @@
+Trial and acquire features
+
+Raven will no longer be a download and try anonymously application.
+There are only two ways for a non customer to trial: immediately online or self host.  Both methods require the user to register to trial and the key will be automatically fulfilled.  
+In no case will a user be able to install a trial key without the database being erased to prevent serial trial scamming.
+
+LICENSED CUSTOMER ADD-ON TRIAL
+Users that are already licensed and just want to try out a feature will get a normal licensed key with the feature licensed as normal but with short expiry like 30 days.
+Once the feature licensed expires it's not offered in the UI anymore (or it says "A license is required to use this feature")
+This way we do not need to replace the key again with a non-licensed version of the trialed add-on.
+
+PROSPECT ONLINE FULL TRIAL
+Anyone visiting our website who is a prospective customer will be able to trial AyaNova immediately by filling out a form after which a new AyaNova will be spun up with a fixed time limit with full license registered to them but as a trial.
+Inside the trial they will be able to seed data for various scenarios at will
+They can purchase at any time and we will activate it into the online version already set up so they can just start working
+When the time limit expires plus let's say another month the database will be automatically erased and server spun down (container deleted from docker?)
+
+
+PROSPECT SELF HOST FULL TRIAL
+
+When a prospect user wants to trial self host, they will be able to download and install and it will start in unlicensed mode where they can verify it's installed and ready but there is no license so it won't allow normal ops, 
+The only options will be to confirm it's working properly and to request a trial key which will be sent to Rockfish automatically, generate a key automatically and install automatically.
+When a trial key is first installed the database is automatically erased thus preventing them from just endlesssly requestion trial keys to keep using it for free
+user can during trial pick different seed data for various scenarios at will
+They can install a fully registered key at any time by purchasing from within AyaNova (at first may need to be via current shareit system)
+
+
+FEATURES REQUIRED TO SUPPORT THIS
+
+- We need a management console to view the load on our server and to alert us to slowdowns so we can expand the virtual server, also we need to be able to do it in more than one datacenter as we would want local endpoints for users ultimately
+- RockFish or some other application needs to be able to spin up a new server and db combo that is unique (docker container?) automatically and prune or get rid of it completely after XX days after trial has expired and it is still unlicensed
+- Rockfish automatic trial key fulfillment and delivery and installation
+- RAVEN built in form to request trial key and automatic fulfillment and install including db is erased any time a trial key is installed when a user already has a trial or no key installed
+- RAVEN built in purchase feature
+
+

devdocs/specs/core-ui-design.txt

@@ -0,0 +1,50 @@
+UI DESIGN DOC
+
+Requirements
+    - Responsive but favoring larger screens primarily
+        - Smaller screens will be able to do everything but the layout is not the primary one
+        - Service techs have an ipad or notebook
+        - Anticipate a list of things each role needs immediately in front of them and try for that
+    - componentized UI elements so can re-use and mix and even support customizing with user defined layout
+        - So for example a customer list is a self contained subset of a list widget and can be plunked down anywhere required
+        - This will save me time so identify the "types" of ui elements (picklist, filterable data list, entry form etc)
+            - Then can build specific versions of the types identified like a client list is a specialized filterable data list etc.
+                - If a list then it also knows which element is selected or a list of selected elements so other widgets can operate on it
+            - A menu or command widget that can be inserted into another widget, i.e. a part picker for a workorder part list widget or elsewhere a part is required
+            - This way I'm only making a few UI objects, not a new one for every single element.
+                - Kind of making the pallet first of all required objects then I can "paint" with them on to the UI without getting bogged down in minute details every time I make a form
+            - UI elements should be responsive and generic enough to work for many different use cases
+            - they should be rights aware and mode aware (editable, read only) enough to handle all that without recoding again and again
+            - the page or shell or whatever that holds the widgets should be end user customizable from a widget pallet.
+            - The more self contained the widget the more useful
+
+    - Most people seem to prefer WBI over RI and the reason always seems to be RI is too simple or requires too many clicks
+    - So plan on the bigger screen layout being the main UI and smaller screen secondary    
+    - I want things to be simpler and cleaner than it seems many people do so beware of that tendency
+        - People don't want to have to open sub screens any more than absolutely necessary
+        - Make sure a screen contains as much as possible to complete it on one screen
+    - Clean interface with good negative space but not dumbed down too much
+    - Pro-marketing style, stuff that makes it easier to sell
+        - emphasize simple fonts with good contrast
+        - Blue is a good colour, no purple or pastels
+    - DAshboard / customizable UI
+        - Ideally people can see as much detail as they want or remove unused ui widget elements
+        - So, for example on the dashboard they can customize by plunking down a client list widget, adding a "My workorders" widget for a tech
+        - or for a Ops person they can plunk down on their dashboard a current server status widget or active jobs widget etc
+
+
+Graphics and themes for AyaNova
+    - No bitmap graphics, vector only!!
+    - I like material design but it will remain to be seen for the front end.
+    - For the manual and docs will use material theme with MKDOCS generator.
+
+
+LOGO
+    - Need to standardize on a logo and stick to it from now on
+    - Simple and clean (script AyaNova used for RI is maybe out)
+    - Single colour canucks blue with green contrast if absolutely necessary (don't make it necessary)
+    
+COLOURS
+    - Canucks colours of course, Blue primary and green secondary. RI already uses them, get the hex codes there.
+    - No indigo or pastels 
+

devdocs/specs/hosting.txt

@@ -0,0 +1,14 @@
+HOSTING
+
+We will be hosting users in rental mode and for trialling, we need systems in place to support that automatically, see core-trial-evaluation doc for more details
+
+- We need a management console to view the load on our server and to alert us to slowdowns so we can expand the virtual server, also we need to be able to do it in more than one datacenter as we would want local endpoints for users ultimately
+- We need to be able to tell if a specific AyaNova server is consuming disproportionate resources.
+- We need some kind of way to cap the load on a server autoamtically so they can't just have thousands of clients attempting to connect at once (i.e. they should self host if they are over a certain size / bandwith usage)
+- RockFish or some other application needs to be able to spin up a new server and db combo that is unique (docker container?) automatically and prune or get rid of it completely after XX days after trial has expired and it is still unlicensed
+- Rockfish automatic trial key fulfillment and delivery and installation
+- RAVEN built in form to request trial key and automatic fulfillment and install including db is erased any time a trial key is installed when a user already has a trial or no key installed
+- RAVEN built in purchase feature
+- Rockfish built in ability to work with built in purchase to license a user and for RAVEN to check in with for new license info (i.e. monthly rental charge and license fulfillment)
+
+

devdocs/specs/marketing-sales-planning.txt

@@ -0,0 +1,269 @@
+MARKETING AND SALES IDEAS
+
+
+We will have two markets:
+
+SAAS rental market
+    - User pays monthly fee to use RAVEN on our servers
+    - Pricing will be a factor of how many scheduleable users, accounting add-on and some kind of protection for us relating to bandwidth and number of simultaneous users
+        - Taking into account support and upkeep costs, hosting costs  etc
+        - One flat price per month, as long as they keep paying they keep using and will get automatically updated and support included
+        - When they stop paying they can no longer use it but we won't delete the data immediately but give them time and warnings before we do   
+    - User has the option to switch to a perpetual license by buying one in which case they can then run it self hosted or elsewhere
+        - This is important to marketing because it removes one of the negative preconceptions around risk using an online service (vendor bankruptcy kind of issues)
+
+Perpetual market with maintenance subscriptions
+    - User buys a perpetual license for the software itself
+        - specifically this means they buy service tech licenses to add in single or groups with discount per group (to be determined based on what makes us the most money and target market)
+    - User pays for support and updates subscription either monthly, yearly or 3 yearly with increasing discounts for each
+        - User can update at any time while active
+
+
+
+WHAT WE ARE SELLING
+
+SAAS RENTAL
+    The ability to use the software for month to month priced by number of techs, accounting addon and whatever we deem to be the fair price to us for server hosting plus bandwidth overages
+        - ideally charge them for a 20 dollar server but use a 10 dollar server kind of thing
+
+Perpetual:
+AyaNova service technician licenses by count with sliding discount for volume purchases at time of purchase
+Accounting add-on
+Maintenance subscription for support and updates
+    - First purchase includes one year of support and udpates (or maybe a shorter time frame at a lower price? Have to research that to see what gets the most revenue)
+    - Subsequent years are at a rate based on whether they have the accounting add-on (one flat price) and so many dollars per service tech but sliding scale so costs less the more techs
+
+PHRASING
+Marketing will sell the licenses with the phrase "service technician" or whatever the most universal equivalent is with a blurb at the top 
+explaining that a "service Tech" just means anything you schedule so could be busses or etc, but then forever afterwards just say service tech as it's less confusing
+
+
+
+
+
+WORKSHEET PLANNING STUFF FOLLOWS:
+
+
+POTENTIAL NEW LICENSING SYSTEMS
+
+What we need:
+	- Absolutely need recurring revenue, no two ways about that, it's our bread and butter
+	- Ease of administration and ease of billing procedures 
+		- Automated system as much as possible for both us and the client
+
+What our customers need
+	- Clear and easily explainable costs
+	- Ease of purchase and control over billing system
+	- Easy to upgrade or downgrade the level of licenses and options
+	- A reason to keep paying and not simply cancel a subscription when it suits them
+
+
+
+SUBSCRIPTION / RENTAL / SAAS LICENSE
+	- Users pay a subscription fee to be able to use the software 
+	- Includes support and updates as long as their subscription is active
+	- Software does not work without a subscription at all, they are renting the software
+	- Quote from a link below: Prices for annual subscriptions are generally some fraction of the perpetual license alternative.  
+		Many companies aim for a crossover point of 4 to 5 years after which the costs for the annual license begin to exceed the perpetual license fee plus the annual support costs. 
+		So, an annual license might be priced at 40% of a perpetual license.
+		- Not sure about that math
+
+
+SAAS PRICING MODELS COMMONLY USED
+
+FLAT RATE
+	- Same flat price for everything for everybody, i.e. 300 a month all in
+	- PROS: Easy to sell, market and explain
+	- CONS: rarely used less precedent, harder to extract value from different market segments, you get one basically, no flexibility for the customer
+
+
+USAGE BASED
+	- Charged based on actual usage, some metric from the software, perhaps number of records or speed of access or space consumed or something
+	- Workorders per month or scheduled items per month would be a good metric for us
+	- Often used for scenarios where someone is hosting something and paying for the costs to host it, i.e. if we were hosting for people
+	- PROS: price scales with use, reduces barriers to use, scales for heavy users compensating for extra costs
+	- CONS: rarely used less precedent, harder to predict revenue, harder to predict costs for the end user, 
+
+CAPACITY / INFRASTRUCTURE *
+	- Based on something that represents the size of the company
+	- We sort of do this now with the price per scheduled user tiers
+	- Normally it's done with some kind of hardware or other consideration such as the size of the server in use based on the number of CPU cores on the machine
+	- Idea is it's cheap for a small company and more for a larger company
+
+TIERED PRICING *
+	- Multiple packages at different price Points (MOSTLY THIS IS ABOUT VOLUME, NOT FEATURE DIFFERENCES SPECIFICALLY)
+	- Usually Small, medium and large (3.5 options is the average)
+	- Basic, Pro, Enterprise
+	- Targets a customer type for each tier trying to take into effect the needs at each tier with an appropriate level of service
+
+	- PROS: 
+		- Commonly used pricing model so easier to market and for people to understand and compare due to familiarity
+		- appeals to multiple buyer personas better chance of a sale
+		- maximize revenue (offering a single $100 package will overcharge users with a $10 willingness to pay, and undercharge users willing to spend $200.)
+		- clear upselling route
+	- CONS: 
+		- Potentially confusing (Do not have too many tiers, maybe 3 with an out for excessive costs to us like too much bandwidth or too many support requests)
+		- Appeals to too many people (don't try to have a tier for every segment)
+		- Heavy user risk (if top people exceed expected costs no room to move them up [This would be solved by having some kind of cap and overage charges I guess])
+	
+
+PER USER PRICING
+	- Exactly what it says, per POTENTIAL user of the software.  1 user one price, 2 users double the price 3 treble etc etc.
+	- Paid monthly or annually (discount of 12% for example)
+	- PROS: Simple, revenue scales with users, predictable revenue
+	- CONS: Hard to track, limits adoption as it can get expensive and so people might hold off too many users which increases churn due to less users tied to prodcut, rewards cheating, doesn't reflect real value; company doesn't see the difference from one user to 5 for them
+
+
+PER ACTIVE USER PRICING
+	- Only charge per active user, don't pay for accounts that are unused
+	- Often targetted at Enterprise level customers
+	- Slack is a famous example
+	- PROS: Customers only pay for what they actually use so reduces their risk of widespread adoption as it won't cost any more if they end up not using it
+	- CONS: Not much value to a smaller business so extra incentive, not idea for us because it means we don't have defined recurring revenue just like the USAGE BASED model
+
+
+PER FEATURE PRICING
+	- "Features" as value metric, not "users" (kind of a mix of what we do now)
+	- Tiers as in TIERED PRICING but by packages with sets of features more than by usage
+	- PROS: strong upgrade incentive, Compensate for delivery heavy (expensive to provide) features
+	- CONS: Difficult to get right (hard to determine which features go in which package could get ugly), Leaves a bad taste / easier to feel resentful for the customer as they know they could be getting more
+
+
+FREEMIUM PRICING
+	- Tier but with a free level to hook people in.
+	- Pricing begins along a dimension of features, capacity or use case (you can use it to do this but not to do that; e.g. not free for commercial use)
+	- PROS: foot in the door, viral marketing potential for word of mouth
+	- CONS: Revenue killer; all revenue to support free needs to come from paid, increases churn, can devalue your core service
+
+
+
+=-=-=-=-=-=-=-=-=-=-=-
+
+OUR PRICING STRATEGY
+	- What is our pricing strategy?  
+	- Example pricing strategies
+		- Penetration Pricing: "land and expand" initial unsustainably low pricing for short to medium time period to grab a market then upsell later once you have a big base
+		- Captive pricing: low intial price for "core" product but lot's of add-on's that are required to really use it and those generate the revenue (inkjet printers)
+		- Skimming pricing: start with an initial high price and slowly lower it over time (not sure this works in our market)
+		- Prestige pricing: maintain a high price to convey prestige or have a high prestige tier (with a rounded price $500 not $499.99)
+		- Free trial pricing: free month then charge to continue usage.  Industry average is 50% adoption rate after free trial and 30 days is the average length
+	
+	- I want it to be easy enough to sell that we never have to hard sell anyone on it or waste time convincing them, we don't want to have to do "sales" at all
+	- Penetration or low pricing will give us growth and our expenses are not high so the more recurring revenue from as many sources as possible the better.
+	- Rather see 500 low price customers than try to fight to keep 3 high price ones, far less risk
+	- Possibly this means that we would take an average less profit on each sale
+	- I'd like to see all options available for all users as much as possible.  Maybe tiers based on scheduleable resources still?  But that's hard to understand for users.
+
+
+
+=-=-=-=-=-
+PRICING PSYCHOLOGY
+	- Price Anchoring: 
+		- set an anchor price by highlighting the most expensive package first on the marketing page so that people judge the other prices by comparison to it
+			- Maybe make the leftmost the most expensive or just otherwise highlight the most expensive so eyes are drawn to it first
+		- Always start with the most expensive price first when marketing or discussing with a customer
+	- Charm pricing 
+		- People heavily judge the leftmost digit in the price subconsciously so don't sell for $400 sell for $399; people see the 3 and mentally get stuck on it
+	- Odd Even pricing 
+		- People might be getting used to the .99 thing so don't end in .99, use .98 or .23 or whatever instead just keep the first digit low
+	- Product bundle pricing
+		- bundle shit together; causes people to think outcomes rather than about the individual prices
+	- Analysis paralysis
+		- Do not offer more too many options (research suggests 7 options plus or minus 2. So 5 or less is safest.)
+		- The biggest, most successful SaaS companies have an average of 3.5 packages available on their pricing pages.
+	- Center stage effect
+		- use the center column of multiple prices as the "most popular", or one we want to sell the most of; people will choose it more often by default all things being equal.
+	
+
+
+
+REQUIREMENTS
+
+- JSON format
+- secured with hash signature
+- All licensed things are in a collection, not just the add-ons
+	- scheduledusers, accounting etc.
+- Old versions should work with new licenses but not the reverse
+- Has an ID and source values like current keys, ID may become much more important in future
+- ALL TRIAL KEYS ARE REGISTERED TO SOMEONE  NO SUCH THING AS TWO LICENSES IN CIRCULATION WITH THE SAME NAME (i.e. no more "Unregistered trial" meaning it's a trial, every user will have a specific name to test it out)
+	- Rockfish issues the trial key upon first request to empty db
+	- Need indicator that it's a trial key / evaluation key
+
+- All licensed things should each have an expiry date possible to turn off that feature
+	- In the case of options they just stop working
+	- In the case of main user license everything stops working
+- MUST be able to support monthly billing cycle (automatic license installation or approval so user doesn't have to install key every month)
+	- Rockfish should have a licensed yay or nay or new available route for RAVEN to check periodically and also users can trigger a force check
+- RAVEN checks periodically for new license to fetch in line with billing cycle or expiry cycle.
+	- SAFE fallback if can't contact license server and allow a few misses before something kicks in, but not to allow people to use unlimited by blocking rockfish for example
+- Support both perpetual license with rental maintenance subscription and rental license
+	- Need expiry date for maintenance so code can query if eligable for updates or support requests
+	- Need expiry date for entire license for rental and trial scenarios
+- Support update restriction based on build date and license
+
+- ?? what about the add-on's expiring at the same time as the sched users.  currently the expiration dates differing is a hassle, should it be still supported??
+- ?? what if we are not licensing by scheduled users anymore but by something else
+- ?? need to analyze sales and determine the percentage of each level of license issued so I can group into tiers
+	- Current (5/29/2018) active subscription licenses:
+		- Single = 35
+		- Up to 5 = 18
+		- Up to 10 = 10
+		- Up to 15 = 1
+		- Up to 20 = 12
+		- up to 50 = 0
+		- Up to 999 = 0
+		- QBI
+		- QBOI
+		- PTI
+		- WBI
+		- RI
+		- MBI
+		- OLI
+		- OutLookScheduleExport
+
+
+Maybe what is needed is:
+	- A single license expiry date no matter what is in the license
+	- A single support and updates date no matter what is in the license
+	- A single license "type" to support tiered pricing
+		- Tiers: 1 user, up to 10, up to 100, custom?
+	- Discussed with Joyce and she made a good case for one by one license sales as most customers are small and tiers may not help as they are in the 10 and under stage anyway
+		so maybe no tiers at all, just licenses for "service technicians" or some more generic term and make a not early that a "service technician" is any scheduleable resource 
+		and then cotinue to use the term service technician afterwards because it's what the majority are scheduling and it is far easier to explain.
+		For the rental market though we will really need to take into account bandwidth so in future there may be more types of things to track.
+		
+
+
+
+
+
+
+PRODUCT LICENSE CHANGES FROM v7
+
+
+Still optional and purchased separately as a single Accounting interface option:
+QBOI, QBI, PTI
+
+Possible idea: sold as "Accounting add on" and the user can use one of those of their choice and can switch which means 1 product instead of three which might make keys easier.
+	Possible downside is that we can't track who uses what or what we sell how much of so puts a kink in marketing or planning for deprecation or where to spend 
+	effort, however there are other ways of addressing that.
+
+
+//INCLUDED ADD-ON's
+OLI - INCLUDED / TURNED INTO GENERIC FEATURE IMPORT / EXPORT CONTACTS and SCHEDULE TO ICAL 
+OutLookScheduleExport - INCLUDED / TURNED INTO GENERIC SCHED EXPORT ICAL FORMAT
+Export to xls - Included with RAVEN
+QuickNotification - Included with RAVEN
+ImportExportDuplicate - Included with RAVEN
+RI/WBI/MBI - UNNECESSARY with RAVEN
+
+
+
+=====================================
+
+RESEARCH SOURCES
+- http://www.reprisesoftware.com/blog/2017/08/implement-a-recurring-revenue-license-model/
+- https://www.linkedin.com/pulse/20140819084845-458042-the-change-from-perpetual-to-subscription-based-software-licensing
+- http://software-monetization.tmcnet.com/articles/429528-long-but-rewarding-road-a-recurring-revenue-model.htm
+- How to calculate pricing in a service business: https://www.patriotsoftware.com/accounting/training/blog/how-pricing-services-strategies-models-formula/
+- SAAS pricing models: https://www.cobloom.com/blog/saas-pricing-models

devdocs/specs/noteable-changes-from-v7.txt

@@ -0,0 +1,10 @@
+NOTEABLE CHANGES 
+
+
+This is a list in no order of noteable changes in RAVEN from v7.
+This is for the purpose of writing an overview and change doc for RAVEN release.
+
+
+REGIONS
+    - Gone, now tags
+    - Restrictions feature of regions gone, new roles might help for this scenario (limited roles)

devdocs/specs/part-category-deprecated.txt

@@ -0,0 +1 @@
+Replaced with tags case 3373

devdocs/specs/plugin-dump.txt

@@ -0,0 +1 @@
+Consolidating all import export to one plugin, see case 3503

devdocs/specs/plugin-export-to-xls.txt

@@ -0,0 +1 @@
+Consolidated all export import to one single feature see case 3503

devdocs/specs/plugin-outlook-schedule.txt

@@ -0,0 +1,7 @@
+FIRST OF ALL CHECK TO SEE WHO IS USING THIS OR ANY OTHER FRINGE PLUGINS
+THAT IS A CURRENT SUBSCRIBER
+
+Consolidate all outlook sched related plugins to a single way of dealing with outlook.
+Also maybe different types of schedule like google calendar etc etc
+
+Might even be related to case 3503 the dump utility as it could dump sched items to ical format or whatever

devdocs/specs/priorities.txt

@@ -0,0 +1,2 @@
+Would like to replace with a tag, but they have colors.
+No cases regarding this that I can find in a quick search, but I suspect there was something somewhere, will update here when found

devdocs/specs/todo-before-release.txt

@@ -0,0 +1,33 @@
+TODO related to Release
+
+
+These are items that should be handled before release, a checklist of last minute stuff
+
+ROCKFISH License key route stuff, make sure it's ready to make requests adn handle customers in real world scenario
+RAVEN LICENSE KEY TRIAL 
+    - make sure the various workarounds to enable trial key fetching are disabled / removed, see License.RequestTrialKey and various others
+        - Basically, if you remove the special CONST guid trial dbid value the rest of the code that needs to be changed should jump out due to compiler errors
+
+DbUtil::DBIsEmpty() 
+    - Check that shit was updated to ensure all relevant tables are involved
+
+
+All dependencies in AyaNova.csproj project file should be locked down to a version release
+    - for example "Npgsql.EntityFrameworkCore.PostgreSQL" package should be set to a determined last change version
+    - Then test everything, confirm all ok, and no more changes to that file until determined after release it's safe to do so
+    - It should be a snapshot in time.
+
+figure out the tiniest possible distribution and which docker container from Microsoft it will work with
+    - right now using sdk version on DO server because of fuckery, but ultimately it needs to be the minimal possible
+
+Branch / tags / repository
+    - Need to figure out how to branch and tag properly so can start on next version without affecting release version
+    - In other words snapshot the release in the repo.
+    - Currently it's not an issue, but maybe it should be done properly
+
+Remove widget route from release (or hide it) but keep in debug
+
+DOCUMENTATION TODO's
+
+Do a search for "TODO" all caps in the docs, there are things that are on hold and need to be fleshed out.
+Do not release with the todo tag in there still!!!!

devdocs/specs/todo-original-todo-doc.txt

@@ -0,0 +1,246 @@
+# TODO original todo docs
+
+This was my original todo doc which I've pared down to only what I want to work on a few steps ahead.
+Keeping this for reference as it has a lot of ideas about core services etc that will be useful
+
+
+
+									
+									
+								    	A NEW START
+									
+									
+
+Get shit done:
+
+Use an agile like process and start coding ASAP with the lowest level pre-requisite stuff.
+
+I get stuff done faster when I see results and coding isn't bad to start early as long as it's done in the correct order and is iterated agilely
+
+Code tests and then code against them, don't get crazy about unit testing every little thing, just what is necessary to validate
+Using an agile-like process re-iterate and continually add new stuff while testing.
+
+
+I want an installable, testable product ready to deploy even if it only has one feature and no front end yet.
+
+Then starting from that base, add in all the common, shared, features first.
+
+Ideally we have a real product that can be installed and run as soon as possible and then build onto that and iterate, adding feature by feature.
+
+
+1) Determine the first things to implement, ideally everything that isn't a business object requirement, bootstrap process, configuration etc.
+2) Implement the core with sysop stuff, generator equivalent, db, maybe not even any user accounts yet, just the framework
+	- Want to be able to install as in production, start the sever, configure, view the sysop stuff make an online account and test there etc
+3) Add a single simple business feature, maybe login and user creation, license etc
+	- Code the front end for that feature, at this point need shell and etc.
+	
+4) Test all the above be sure about it, make sure it follows the guidelines for coding standards etc, then get into the actual features
+5) Code AyaNova business features
+	- ** DO NOT WASTE TIME PLANNING AND DOCUMENTING EXISTING UNCHANGING FEATURES, LET AYANOVA SOURCE BE THE GUIDE FOR THAT **
+	- Just document changes or new stuff only
+	- This is where we get into the stuff below and the biz object cases etc
+	- Code in order from the simplest most fundamental objects towards the most esoteric and complex multi object items
+	- Save the most complex objects for last so as to save time as no doubt changes will come up in other coding
+	- For example, there are no doubt objects that are mostly standalone and don't involve a lot of other objects, start there
+
+	
+ 
+
+
+
+
+
+
+
+
+
+******************************************************************************************************************
+******************************************************************************************************************
+								OLD PLAN BELOW HERE KEPT FOR REF BUT NEW PLAN SUPERSEDES
+******************************************************************************************************************
+******************************************************************************************************************
+		
+		
+		
+		
+
+## FEATURE PLANNING / RE-ORG / AUDIT CASES 
+
+- PLANNING STEP 1: Go through all AyaNova 7.x, 8.x cases and any other places there is feature stuff
+	- Move to RAVEN the ones that are worth keeping / looking into (snap judgements)
+	- Set all cases moved to Raven to priority 3 indicating unprioritized
+	- Stuff that will never be done for sure just close.
+	- Stuff that won't be done in RAVEN but might be worth keeping until the release of RAVEN before closing drop priority down to 5 
+	- When done there should be no more cases above priority 5 in 7.x unless they will be fixed in 7.x	
+	
+- PLANNING STEP 2: Examine RAVEN cases and re-prioritize and categorize them:
+	- SET THE CATEGORY COLON DENOMINATED i.e. (CLIENT, REGION, WORKORDER:TASKS:CR:NEW, UI, SECURITY etc) by prepending the title with the category.
+	- If it's completely new feature then the last tag should be ":NEW"
+	- IF it's customer requested put a :CR tag in the title
+    - UNPRIORITIZED
+        - default for items until I categorize them
+        - PRIORITY 3
+    - MUST HAVE IN INITIAL RELEASE 
+        - PRIORITY 1 and 2
+        - flag as highest priority 1 for work on first and 2 for work on secondly
+    - SHOULD HAVE IN FUTURE RELEASE
+        - PRIORITY 4 and 5
+        - flag below highest as priority 4 or 5 depending on urgency   
+
+- PLANNING STEP 3 THE WORKORDER LAYOUT
+	- This is tricky so needs a whole step
+	- Determine new workorder layout and structure
+	- Don't need exact features, rough is ok
+	- Step 4 will get into the details of the workorder
+
+******************************************************************************************************************
+******************************************************************************************************************
+								NOT DONE BELOW HERE
+******************************************************************************************************************
+******************************************************************************************************************
+		
+
+	
+				
+- PLANNING STEP 4 FEATURES DOCUMENTS 
+	- Read through my own notes in CODING-STANDARDS doc and REASEARCH.TXT and SOLUTIONS.TXT 
+		- VERY IMPORTANT stuff in there, a lot of sysops stuff and practical decision stuff
+		- Review it all and update any related cases / make new cases as appropriate.
+
+	- Read through and triage Joyce's notes and docs for her v8 work.  
+		- I've re-written them all out sorted by last edited date
+		- This will then be gone over more deeply as input into the later stage of feature development below
+	
+	- Go through AyaNova and all it's add-on's and put major feature areas into a list in features.txt
+		- Then, go through all cases and all of Joyce's v8 docs for that item / area and create a document for each feature area
+			- Fill in with the features and changes to that item in order of implementation
+			- IMPORT: Important that I also document how existing data will be imported for this feature
+		- If a completely new feature is determined then it needs to be in there as well (tags)
+		
+	- Find common features that are shared with objects so they can be "Interfaced" and planned for
+		- Tag handling, UI preferences and MRU's and user settings
+		- Localization stuff
+		- Notification
+		- Common menu options that are shared by objects
+		- Need a set of sections that deal with just this kind of thing as it will be coded FIRST.
+		- Common UI widgets Document every common UI widget needed and where.
+			- The RAVEN ui will be made up of a lot of tiny widgets that are re-used here and there, that's what I will be making so need to document that
+			- Essentially everything in the UI will be a bunch of widgets housed in a bunch of modules housed in a shell
+			- Identifying them all up front will save tremendous time in development
+			- For example: in lots of places we need to show a filterable list of workorders tied to the object being viewed
+				- Like on the client form you need to see a list of workorders for that client
+				- On the unit form a list of workorders for that unit 
+				- So a WORKORDER LIST widget is one that will be re-used time and again so document that and it's features
+					- Then it's just a matter of snapping it into any area it's needed
+				- this will translate to a business object and probably a route in the api etc etc
+			- Search widget and results display, that kind of thing
+	- Identify the first object to code, ideally it should have the most common features and the least of it's own features so I can focus on the shared stuff.
+		
+	
+	- What I want to end up with is a set of documents one for each major feature 
+		- In each document I want to list what is kept, what is changed and what is new
+		- Add points of what each feature currently does and needs
+		- Then go through the cases and note new and changes relevant to that object
+		- Consider and make decisions and rank as priority 1 (in first release) and priority 2 - subsequent release
+		- iterate until there is at the end what I'm after
+		
+		- This is the list I will work from to ensure everything gets done
+		- I want each documents items in the best order of implementation as much as possible
+			- THIS IS IMPORTANT: I don't want to code a feature then see that I should have done something different later
+		- Then I can go through it while coding as my todo list basically
+		- Ideally then can test as each object is ported, kind of like each object is a new feature in quick release cycle	
+
+
+  
+- PLANNING STEP 5 USER INTERFACE
+	- Design the user interface for each section above, I want to see visual design that I can work from instead of winging it.
+	- ?? Need a design for at least two views, desktop / tablet and phone but need to research this a bit I guess
+	- Doesn't need to be perfect, a rough sketch and placement is fine.
+	- Need to design the widgets essentially
+	- Need to account for each view depending on ROLE viewing it.
+		- Find the commonalities for the roles so there is a pre-defined levels of access for each widget that match roles
+			- Like a Read only limited view, a full control view, a whatever view, each type named and replicate concept to all widgets
+		- Widget should be aware of roles and what to allow for each of them
+
+- STEP 6 CODING
+	- Code the NFR / SHELL and fundamental / common features like tag handling etc.
+	- Since a widget is kind of standalone ready, maybe a widget playground to test out widgets on a blank canvas without worrying about shell stuff at first.
+		
+	
+
+	
+	
+	
+
+
+- HOSTING planning
+    - Just a light initial assesment will not be super important at first, only interested in big picture stuff that might affect coding
+    - What will we need for hosting?
+    - What is the unit of software that each customer would use
+        - I.E. do we have one container per customer and spin them up as required
+    - Apply to design
+
+
+
+
+## INITIAL CODING: FRAMEWORK SKELETON ALL NON FUNCTIONAL REQUIREMENTS
+
+- Make a list of all the things that it should do for front and back end
+- This is really the foundational skeleton of everything and is the most important step, if it takes a while so be it, it will save a fortune in time later 
+- The design should be frozen once this skeleton satisfies NFR
+- Once this is in place then can just fill in functionally required code and objects from design
+- It's also a reference point for any other new projects going forward so keep a snapshot / Subversion tag that THIS IS IT!!
+- There should be no research or figuring out required after the skeleton is completed (ideally)
+- Build initial framework first with all the "non functional requirement" (everything but the actual business classes) specific features in it. Take a snapshot so it can be the basis for other projects in future.
+- All tools should be in place
+    - Development tools
+    - Testing tools 
+        - Once we have something to test look into something like: https://jenkins.io/solutions/docker/ containerized?
+        - Unit
+        - Integration
+        - Load
+    - Building tools 
+        - Once we have something to build look into something like: https://jenkins.io/solutions/docker/       containerized?
+    - Releasing
+    - versioning
+    - updating
+    - containerization 
+    - All database types
+    - Installer / installation
+    - Management interfaces or tools
+- BACK END API
+    - Sample routes with two api versions (0 and 1.0)
+    - ideally a small sample of code showing all the layers of code involved with all the NFR features desired like circuit breakers you name it
+        - Users and Client for starters with a list of clients, a client entry and edit and delete
+        
+        - dependency injection / loose coupling
+		- https://joonasw.net/view/aspnet-core-di-deep-dive
+
+
+    - Upgradeable
+    - Versionable
+    - Circuit breakers
+    - Performance and other metrics and logging
+    - All the NFR in the PROCESS and BEST PRACTICES section of my coding-standards doc
+- UI Skeleton to support this backend skeleton
+    - All NFR that are UI level (a SPA web application)
+    - UI concerns that may affect back end stuff should be in the skeleton
+    - The guts of the UI presentation host whatever it's called without the actual specific bits to the app
+        - Loading
+        - Upgrading
+        - Handling errors
+        - talking to the api
+
+- TESTING
+    - 
+    - Smoke test first in a limited test VM that simulates a droplet of 512mb ram, 1cpu, docker container with db etc
+    - Test in a DO droplet under load with lots of data and see what memory and cpu and disk resources are required and how it performs  
+    
+
+
+
+## FR CODING
+    - After the above move on to functional requirements coding
+    - Test and deploy daily at least
+
+

devdocs/specs/unit-of-measures.txt

@@ -0,0 +1,2 @@
+DEPRECATED?
+Still not decided yet but leaning heavily towards ditching it, see case 3433 and 2038

devdocs/specs/unit-service-type.txt

@@ -0,0 +1,3 @@
+Deprecated for tag?
+Didn't actually check but it seems like a likely candidate.
+See case 3373

devdocs/specs/user-certifications.txt

@@ -0,0 +1,2 @@
+Deprecated maybe?
+See case 3440, 1138

devdocs/specs/user-skills.txt

@@ -0,0 +1,2 @@
+Deprecated maybe?
+See case 3440, 1138

devdocs/specs/user-wiki.txt

@@ -0,0 +1 @@
+WTF do we need this for?

devdocs/specs/workorder-categories.txt

@@ -0,0 +1,2 @@
+Deprecated to tags (verify this is possible)?
+See case 3373

devdocs/specs/workorder-item-type.txt

@@ -0,0 +1,3 @@
+Deprecated to tags?
+See case 3373
+Need to confirm it will work, types don't appear to do anything and are documented as for filtering and reporting and sorting so that's a tag