devdocs/todo.txt

@@ -15,62 +15,25 @@ THINGS HOLDING UP PERPETUAL RELEASE
 - Announcement email with migration plan and costs and offers etc
 
 
-todo: rockfish needs to be able to enter a shareit sale of raven licenses (all the features like paste in etc)
-	product codes already added 
 
-todo: implement and test new system to prevent download subscription instance database and just use locally, i.e. check for special file or whatever system we implement
-	 check for subscription key file presence and signature inside to be checked in case they parse the code and put teh file by that name needs to be not enough but signed inside too
-todo: ROCKFISH different license key signature if it's a SAAS license
-	this solves a lot of problems, effectively it's unlicensed if they move their data to their own hardware without a key
-	requires that AyaNova have different internal key to check, maybe it's actually a build switch for that since only we will be running our SAAS version.
-	dual signatures doesnt' work becuase it would mean ayanova could just work anyway since it can check either, need something else.
-	build switch would work but it means a whole separate build every tiem which is fucky, but maybe necessary.
-todo: LICENSE must prevent a user from moving their data from perpetual to sub and vice versa without the right key so we can control it
-	otherwise they could just download the data and run it locally as it's got the license in it
-	See immediately below potential solution
-	CONSIDER: is this an issue?  If so how to control it, maybe some kind of file flag or invisible config key or something??
-	This has implications for competitors running subscription services
-		i.e. havabyte says I'll host it for you just download your data and send to me and I'll do it for less
-			The critical part is the update, if the license permits updates for subs it has to be only when we do it
-			otherwise they self host and enjoy free updates unless we zap the license..hmm... needs something more here
 
-			Maybe they can't download the backup with the license intact??
-			Maybe they can't intereact with the license page at all if it's subscription, just view it??
-todo: SAAS different license checking method to ensure only *we* are hosting it if it has a saas license
-	something location dependant, a different license server address?  
-	We might host with other than digitalocean at some point so we can't look for that as a key
-	I guess we have our own approved IP addresses maybe in rockfish, if the license request comes from anywhere else than set for that customer we go fuck no and shut it down??
-	Does digitalocean ever change the ip address?
-	** Actually a static file outside of the backup would be ideal as it is easily transferrable by us, doesn't rely on ip address fuckery and can contain a signature inside it just like the license does, same key so we know it's legit
-		and if no file present then it's not hosted by us and as long as the license is perpetual then we're ok, but if the file not present and it's an SAAS license they fuck that shit stops working says not running from a licensed location.
-TODO: I think a different build is the most solid way to do it, it's a pain but it *does* solve a lot of problems in one swoop and I can do endless things in the code if I have a build flag around them that is cool
-	implement build flag "SUBSCRIPTION_BUILD"
-	Raven trial request must send it's build type to get the appropriate type of license
-	Rockfish must return the correct type of license for the requested build type
-	Change rockfish license generator to make subscription type a first class element, not a feature in the feature collection
-	change AyaNova build to only work as a subscription build with a subscription key adn vice versa so the key *must* be the correct one
-		treat this like an out of maint newer build where it just won't boot up
-		ensure migration path to this by erasing key and fetching a new one, same db id, just new key
-		can just erase the key and put a purchased one is as a path
-	Change rockfish so we know if they are a subscriber right on the main customer page somehow with an area to put their address and stuff
-	we will be generating a *lot* of keys if they are month to month
-	Do I need a separate subscription expiration date in the key?
-		actually, I think the existing one is there for just this purpose after all a perpetual never expires so maybe no need to fuck with this aspect
-	Test it out as if a real customer were doing this end to end on a hosted server
 
-todo: review above and ensure all is accounted for before proceeding
-todo: figure out new dbid thing, is this becuase it's in the key table or...??
-	maybe need a way to know it *was* license before and is not just any old eval or empty? (for that other todo as well )
+
+
+todo: test trial request both ways and ultimately on hosted server before checking this off
 TODO: test out perpetual build and license to confirm all ok
 todo: test out autofetch code for development work
+todo: Change rockfish so we know if they are a subscriber right on the main customer page somehow with an area to put their address and stuf
+todo: examine client and see if there are any areas where the license is not displaying correctly in the UI with the new license type field and code
+todo: rockfish needs to be able to enter a shareit sale of raven licenses (all the features like paste in etc),	product codes already added 
+todo: test with local dev rockfish a sale process end to end before moving on to posting it
 todo: post rockfish if get to here and all ok
-todo: test existing version at server with new key generator for rockfish??
+todo: Make sure doesn't fuck up existing testers - test existing version 8.0.3 with new rockfish BEFORE POSTING NEW 8.0.4 at server with new key generator for rockfish??
 todo: if all goes well then post to test server and try both ways again and confirm it's ok
+todo: ultimately at the end test as a fake sale right through to licensing so we know it's ready to go!!!! Very important, this is the last thing I need to be dealing with when get in the weeds close to release
+
 
 
-TODO: If erase license from AyaNova db using flag it makes a new DBID, it shouldn't.
-TODO: If erase license from ayanova db using flag login prompts to trial, it shouldn't 
-	need a way to tell that the data doesn't look like eval data, i.e. not empty and doesn't have sample users maybe? Not sure, could doc around this or in instructions too to users if arises.
 
 todo: ROCKFISH can't make a trial key for users in the UI, only when it's requested from ayanova.
 	I'm really not sure if this is an issue or not but putting it on the list in case