Hello! Thanks for the quick reply. Yes and no. Permission base classes and sub classes were not updated in the DB through DBMigrator, but new permission strings within the sub classes are added. For example, if I had a Permission like:
AzurePermissions.AzureServers.XXX and changed it to AzurePermissions.Servers.XXX and then added a new permission like AzurePermissions.Servers.Create the 'Create' permission would be added in the AbpPermissions table. But AzureServers would remain as the parent.
I observed this on a local installation where I have full admin permissions. FWIW, our CI/CD pipeline updates/adds permissions just fine. I'm guessing that's because it first runs DBMigrator, then runs the API backend. And if that's what we need to do from now on, that's fine. It's just a departure from what we have been doing which is simply running DBMigrator and I need to know what to tell other devs that run into this issue.
We have a general question about how permissions get populated in the database. We recently altered several permissions, mostly to better align with naming conventions, and then ran DBMigrator expecting that the altered permissions would be in the AbpPermissions table. However, the AbpPermissions table did not contain our new permissions.
We tried several tests and eventually were able to reliably replicate an issue:
Our PermissionDefinitionProvider class is in the Application.Contracts project, just FYI.
Is there something we are not correctly understanding about how permissions work? Thank you for your time.
Hello. I noticed yesterday that the abp generate-proxy -t ng command is generating proxy files with incorrect imports. Almost all of my proxy model files have imports that look like:
The files have duplicate imports from /models and /*.enum. Is there a known solution or workaround for this issue?
