Project members can't see any of the project's repositories (member role is never linked to asset read)

Summary

Adding a user as Member of a project gives them an empty project: they can open the project, but the repository list is empty and every asset URL returns 404. The only ways to make repositories visible are adding the user as project Admin (which grants update/delete on everything) or adding them as member on every single asset by hand. For an organization onboarding developers per group, that means either over-permissioning or per-repository clicking.

Version: v1.13.2.

Why it happens

The project/asset listing filters by asset-scoped roles:

https://github.com/l3montree-dev/devguard/blob/v1.13.2/controllers/project_controller.go#L345

allowedAssetIDs, err := rbac.GetAllAssetsForSession(c.Request().Context(), shared.GetSession(c))

and GetAllAssetsForSession only collects asset::<id> roles from the user's implicit casbin roles (https://github.com/l3montree-dev/devguard/blob/v1.13.2/accesscontrol/casbin_rbac.go#L222).

But asset bootstrap only ever links the project admin role to an asset role:

https://github.com/l3montree-dev/devguard/blob/v1.13.2/services/asset_service.go#L110

// make sure and project admin is an asset admin - Always
if err := rbac.LinkProjectAndAssetRole(ctx, shared.RoleAdmin, shared.RoleAdmin, asset.ProjectID.String(), asset.GetID().String()); err != nil {

There is no LinkProjectAndAssetRole(RoleMember, RoleMember, ...) counterpart so project members hold no asset:: roles at all. Interestingly, BootstrapProject does grant members project-scoped asset read (https://github.com/l3montree-dev/devguard/blob/v1.13.2/services/project_service.go#L151), but that permission is never consulted by the asset listing or the per-asset middleware, which suggests the missing link is an oversight rather than a design decision.

The same admin-only pattern applies to subgroup inheritance a parent-project member gets nothing on child projects:

https://github.com/l3montree-dev/devguard/blob/v1.13.2/services/project_service.go#L160

Proposal

In BootstrapAsset, additionally link project member → asset member:

if err := rbac.LinkProjectAndAssetRole(ctx, shared.RoleMember, shared.RoleMember, asset.ProjectID.String(), asset.GetID().String()); err != nil {

(asset member already carries ObjectAsset: read), and mirror the member link in the parent→child project inheritance. Existing installations would need a small migration/backfill of the casbin grouping rules for already-bootstrapped assets.

Start with controllers/project_controller.go, accesscontrol/casbin_rbac.go, services/asset_service.go, and services/project_service.go at the referenced locations. Trace how project member roles are bootstrapped and how asset access is listed and checked. Done means project members can see and read project repositories, parent-project inheritance is covered, and existing installations have a migration or backfill for the required Casbin rules.