This seems to directly contradict the FAQ?
"After your license perid ends, you can continue developing your application and use ASP.NET Zero forever. Also, you can always update ASP.NET Boilerplate and module-zero nuget packages, since they are open source projects and will always be open source. You can continue to access all documentation since it's public. But you will not get ASP.NET Zero upgrades anymore, can not access to Github repository. Also, your premium forum membership ends. You can surely use community section of the forum as always. "
<cite>antonis: </cite> So after the license expires we cannot work on the project?
At first I was quite reassured and ready to walk back my comments. It sounds like they thought about this a lot, and implemented a good solution.
But if this is the case and we can no longer develop our application after the license expires, I will have to have a serious talk with the team about abandoning the framework..
I would add that I understand the desire to protect your business by attempting to prevent people from using a single license for multiple products.
However, we have a business to run. We can't have our application depending on external servers that we have no control over.
Why was this added without explanation? Moreover, it's clear the license check depends on an external server resource.
You claim your framework is ours to use in perpetuity once we purchase the product, but this is clearly not the case, if the license checker is dependent on an external resource.
What happens if Volosoft goes out of business? Everyone who purchased ABP Zero loses years of development work?
I'm shocked this was added without input from the community.
<cite>Mdonogma: </cite> this has been on the roadmap for a long time - please can you guys address/ fix in next release.
paypal integration is pointless without recurring payments and a blocker for us from production deployment.
It is not Volosoft's responsibility to write your code for you. If you need a feature that they don't offer for their already incredibly priced product, then write it yourself like everyone else has to. They are very clear about what features come with their product.
There is a post on the issue tracker for this.
I suggested an external plugin we are using, called seralize.JSON, it works well. You can find a link in the issue:
<a class="postlink" href="https://github.com/aspnetzero/aspnet-zero-core/issues/561">https://github.com/aspnetzero/aspnet-ze ... issues/561</a>
I understand that, what I haven't figured out is how to associate permissions with the roles so that when the role is assigned, the permissions is granted, WITHOUT logging in to the application and configuring the role from the back end.
From what I can tell, all permissions are stored at the user level, and assigning a role simply applies the associated permissions.
From the code I found, it's very basic: admin grants all permissions, user grants no permissions.
The permission manager can grant an individual user permissions, but I need to be able to establish preconfigured roles, and seed them accordingly. This should happen through migrations, not a configuration step or while the application is running.
I've read through as much of the ABP and Zero documentation regarding roles, permissions, and authorizations as I could find, but I'm still having trouble understanding how to go about configuring static roles.
The standard static roles are Admin (which has all permissions), and User (which has no permissions.)
For our application, we will have several static roles, in addition to the dynamic roles. These static roles will have permissions associated with them by default.
I know how to add permissions to a user, but how are we supposed to associate permissions with static roles so that when that role is assigned to a user, they are granted the appropriate permissions?
Keep in mind that the github code does not have the renaming applied to the template, so all of the namespaces, and most of the file names will not match your code, making mergers difficult to manage.
We have found that the easiest way to stay up to date is to download the latest release, replace our existing source folder, and then comb through the git changes to isolate any overrides to our customization.
For our Domain and Application layers, we have created 2 new modules so that the majority of our code won't be affected by the merger.
It's not the most ideal process, but it's been working well so far.
Attribute parameters must be constants, so you can't use the L method inside of an attribute.
