Permission Groups, Permissions and Permission Grants not created for new microservice #10833

2 Answer(s)

• 

  0

  AI-Bot created 2 months ago

  Support Team ABP Agent

  • In the microservice template, permission groups/permissions are written into the Administration Service database by the microservice itself when that microservice starts (via PermissionManagementOptions.SaveStaticPermissionsToDatabase, which is true by default). So if the new microservice runs in AKS but its permission definitions are not appearing in AbpPermissionGroups / AbpPermissions, it means that microservice did not successfully execute the “save static permissions to DB” step in AKS (even if it worked locally).

  • Separately: granting new permissions to the admin role is not done by every microservice. Only Administration Service seeds/grants newly discovered permissions to the admin role. So even after the permissions exist in AbpPermissions, you may still not see AbpPermissionGrants for admin until Administration Service runs/restarts.

  What to do (AKS / Helm)

  1. Restart the new microservice pods (not only Administration)
     Permission definitions are persisted on microservice startup. After deploying a new microservice or adding new permissions, you must restart that microservice so it re-registers permissions into the Administration DB.

  2. Restart the Administration Service after the microservice has registered permissions
     Administration seeds/grants the missing permissions to admin when it starts. So do a rollout restart of Administration after the new microservice has come up successfully.

  3. Verify PermissionManagementOptions.SaveStaticPermissionsToDatabase is not disabled in AKS configuration
     In Kubernetes, it’s common to have environment-specific appsettings.Production.json (or Helm values) that differ from local. Ensure you didn’t override this option (directly or indirectly) to false in AKS.

  4. Check the new microservice logs in AKS during startup
     If it cannot reach the Administration database (connection string / firewall / DNS / TLS), or if it crashes before initialization completes, permissions won’t be saved. This is the most common cause when “works on localhost but not in AKS”, especially since you’re using different DB servers.

  5. (If you also don’t see the permissions in the UI) Clear the distributed cache used by AKS Even after the DB rows exist, permission definition data is cached. If AKS uses a different Redis instance than local, you must clear that Redis (or restart services) to invalidate cached permission definitions.

  (Optional) If you want automatic granting to admin without relying on Administration restart

  Add a data seeder in the relevant microservice and call IPermissionDataSeeder to grant permissions to admin (ABP’s docs mention this approach and Identity service uses it).

  ---

  Source (validated):

  • https://abp.io/docs/latest/solution-templates/microservice/permission-management

  ---

  This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  maliming created one month ago

  Support Team Fullstack Developer

  Hi,

  In the microservice solution, each microservice writes its own permission definitions into the Administration database when it starts, using the AdministrationService connection string. This runs in a background task: if saving fails, the service still completes startup and keeps serving requests, and the failure only shows up in its logs. Clearing Redis doesn't help here because the cache is not what writes these rows.

  Since it works on localhost but not in AKS, check two things for the new microservice:

  1. The effective environment of the running pod (kubectl describe pod or kubectl exec ... env): ConnectionStrings__AdministrationService must point to the Administration database used in AKS. The built-in services all get it from their helm charts (etc/k8s/.../charts/<service>/templates/<service>-deployment.yaml). If the new service's chart doesn't set it, the pod uses the appsettings.json value baked into the image (localhost), which is not reachable inside the cluster.

  2. The new microservice pod's logs, from startup onwards - search for errors from Volo.Abp.PermissionManagement and SQL connection errors. Note the save is retried with increasing delays for about an hour after startup, so check the full log, not just the first minutes.

  After fixing the connection string, restart the new microservice pods so the permission definitions are saved, then restart the Administration service - its startup seeder grants the new permissions to the admin role.

  If both look fine, share the logs with us (you can send them to liming.ma@volosoft.com if they're too large for the thread) and we'll dig further.

  Thanks

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel