More subscription license work allow logins addition

devdocs/deploy.md

@@ -6,7 +6,7 @@ If any packages have been changed in the release do a thorough security scan and
 
 ### Bump version numbers:
 
-Search and replace 8.0.6  
+Search and replace 8.0.7  
 webapp,server,launcher, v8migrate (don't change v8migrate unless it has it's own code changes, it's version should be it's own thing other than major release changes etc)
 
 Client end ayanova-version.js,

devdocs/pricing.md

@@ -139,7 +139,7 @@ TWO types makes the most sense after considering options:
 -   One time fee, user can use indefinitely
 -   self installed, hosted and maintained by customer
 -   least profitable for us long term if they don't buy a maint. subscription
--   Without maintenance subscription, eligable for Minor updates only to fix bugs no new features so in other words they buy 8.0.6 they can upgrade to any 8.0.X version release, but not 8.1 as it will be new features added that don't break backward compatibility
+-   Without maintenance subscription, eligable for Minor updates only to fix bugs no new features so in other words they buy 8.0.7 they can upgrade to any 8.0.X version release, but not 8.1 as it will be new features added that don't break backward compatibility
 -   one-time payment, along with the option of a yearly maintenance fee.
 -   This is basically our current model but we allow upgrades for subscribers
 -   **HAS CODE IMPLICATIONS** upgrades need to check if allowed based on version number if no maintenance subscription _not_ on date of build.

devdocs/todo.txt

@@ -35,6 +35,16 @@ WIP >>>>>>>>>>>>>
 todo: move the dbid to the very first position in the shareit order additional fields as only the first two will show in email and reporting
 todo: register domain name myayanova.com for hanging subscriber servers off of
 
+todo: rockfish not putting time limit on subscription keys, UI needs additions and shit for that
+
+todo: restrict superuser account in some critical ways so it can't be used for day to day work, maybe no dashboard etc
+	nothing too serious that it breaks existing code but remove any features that it shouldn't be used for
+	Find a subtle way to do this particularly for subscription users
+
+todo: superuser consuming a license theoretically but shouldn't so in a subscription mode it needs to be locked down as to what it can be used for, some critical features should block it from use
+	fuck! Actually, just automatically deduct it from the count, whatever the count is remove one for superuser (or maybe in query filter OUT the superuser id 1!!!!)
+todo: customer contact consuming a subscription license always because it doesn't knwo if they are a login or just a contact, maybe solution is to not set a login name if they arebn't a login customer
+	and change the counting code to ignore no login name users (but only for the customer contact count, not the inside staff count or that would be used to circumvent licening (or do we care? hmmm))
 
 
 todo: TEST subscription and perpetual license code
@@ -42,7 +52,8 @@ todo: TEST subscription and perpetual license code
 	Does it prevent changing a user type? (direct db meddling)
 	Does it prevent installing a new license when too few for existing active?
 		Does it communicate this well to the user?
-		
+	
+
 	
 
 
@@ -1259,6 +1270,6 @@ https://www.ayanova.com/download/next/ayanova-linux-x64-server.zip
 https://www.ayanova.com/download/next/ayanova-windows-x64-lan-setup.exe
 Current v8 docs home: https://www.ayanova.com/docs/next
 
-BUILD 8.0.6 CHANGES OF NOTE
+BUILD 8.0.7 CHANGES OF NOTE
 
 Subscription / perpetual license code and stuff