devdocs/todo.txt

@@ -25,6 +25,8 @@ todo: License agreement changes for SAAS customers, this is huge and I hadn't th
 	Needs a disclaimer about the right to refuse service if becomes too high usage i.e. subject to usage limitations to cover our ass and check with D.O. how to clamp that from going into expensive territory for us?
 	We also need to mention we will size their servers to adequate work load or whatever meaning we will put them on the smallest cost server that will sustain their needs.
 
+todo: SAAS gaming, once have idea of plans and add-ons, need to test it out on servers and see what's what and how it would work in practice
+	i.e. storage on block storage, backup practical things etc
 
 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
@@ -40,9 +42,10 @@ todo: RENTAL terminology needs to change to "SUBSCRIPTION" in rockfish and in cl
 todo: SUBSCRIPTION should only refer to month to month SAAS feature / plan.  Support and upgrades should be referred to as Maintenance or Support and upgrades without the word "subscription"
 TODO: above changes at SHAREIT with the product descriptions as well so no confusion
 
+
 todo: if SAAS needs to do some things differently:
 	if it helps, consider a different build flag since SAAS is like an internal build for us
-	SERVER - count total active users towards license not techs only
+	SERVER - Count total active users AND SEPARATELY total active Customer login users towards license not techs only
 	SERVER - different signature for license keys
 	ROCKFISH - different signature when SAAS key
 	SERVER - some routes not enabled around licensing, operations etc
@@ -60,9 +63,14 @@ todo: if SAAS needs to do some things differently:
 	SERVER - hide any info about the droplet technical stuff like ram and ops stuff, we don't want them to have an idea how much memory they can have, or do we?
 		maybe it's a plust because we can say you get a maximum storage for attachments of XXGb based on droplet size and it's an add-on to go with a bigger server??
 		Because some people need it and will pay for it if it's offered.
+		YES hide all ops but for ops users or us whatever we need though I guess we can just api our own UI for it
+		They should have an easy way to see storage
 	SERVER - how to cap bandwidth, storage, whatever we get billed extra for from d.o.
+		YES Needs to cap and not allow attachments and warn when getting low on disk space, we're probably ok with db size and can just eat it, who will even get near the capacity for that, it's the attachments that are the bugger
 	CLIENT - NEEDs to report that a new version was installed to the user with link to changes when we publish a new version so they can be made aware
 	EMAIL - research how to send emails with a reliable provider i.e. sendgrid or alike and what the costs and add-on price for that would be.
+	SERVER / CLIENT - BACKUP we can't have them frigging around with it and fucking it up, if we're in charge we need to set the routine and locations etc, if they are in charge need to ensure it's not making too many backups somehow 
+		BACKUP screen should show capacity available in destination backup location
 
 todo: each droplet for SAAS would need it's own ssh key and password to avoid eggs in one basket security scenario
 	also would need to securely store the passwords somewhere really really fucking secure like offline in a special keypass only accessible from certain hardware maybe with a digital key or something I dont' know