admin/raven
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

subscription license code additions

Browse Source
This commit is contained in:
John Cardinal
2022-08-17 03:03:48 +00:00
parent 7d2076d1c7
commit b9d33ff036
11 changed files with 91 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
devdocs/deploy.md
View File

@@ -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.3
Search and replace 8.0.4
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,

2
devdocs/pricing.md
View File

@@ -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.3 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.4 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.

16
devdocs/todo.txt
View File

@@ -58,8 +58,20 @@ TODO: I think a different build is the most solid way to do it, it's a pain but
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 out perpetual build and license to confirm all ok
todo: test out autofetch code for development work
todo: post rockfish if get to here and all ok
todo: test existing version 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: 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
add as a feature just in case
@@ -1281,6 +1293,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.3 CHANGES OF NOTE
BUILD 8.0.4 CHANGES OF NOTE
Allow negative quantities on most work order subitems
Subscription / perpetual license code and stuff