MavenRemote/Repository/DistributionViewSet define no DEFAULT_ACCESS_POLICY — non-superusers can never be authorized regardless of granted roles

[mkkm434389]

Summary

MavenRemoteViewSet, MavenRepositoryViewSet, and MavenDistributionViewSet don't define a DEFAULT_ACCESS_POLICY, unlike mature plugins (pulp_rpm, pulp_file, pulp_deb, ...). As a result:

• No AccessPolicy row is ever created in the database for maven's viewsets — confirmed via GET /pulp/api/v3/access_policies/, which returns zero results for any viewset name containing maven, versus several each for rpm/file/deb.
• pulp role list --name-contains maven returns [] — no locked roles ship with the plugin at all.
• Because customizing an access policy only works via PUT/PATCH /access_policies/{id}/ on an existing row (there's no POST to create one), there is no way — via the API, RBAC, or any documented mechanism — to authorize a non-superuser for these endpoints.

Steps to reproduce

1. On a Pulp instance with pulp_maven installed, create a non-superuser user and add them to a group.
2. Create a custom Role bundling maven.view_mavenremote, maven.add_mavenremote, etc., and grant it to the group model-wide (POST /groups/{href}roles/ with content_object: null).
3. Confirm the grant is present via GET /groups/{href}roles/.
4. As the non-superuser user, call GET /pulp/api/v3/remotes/maven/maven/ (or pulp maven remote list).
5. Actual: Error: Operation remotes_maven_maven_list is not authorized.
6. The identical request as an actual superuser (admin) succeeds.

Root cause

MavenRemoteViewSet (etc.) inherit directly from pulpcore's base RemoteViewSet/RepositoryViewSet/DistributionViewSet without overriding DEFAULT_ACCESS_POLICY. Compare to e.g. pulp_rpm's RpmRemoteViewSet, which explicitly maps actions (list, create, sync, ...) to permission checks (has_model_or_domain_or_obj_perms:rpm.view_rpmremote, etc.) and ships locked roles (rpm.rpmremote_owner/_creator/_viewer) via a data migration. pulp_maven never shipped either, so the viewset falls back to whatever pulpcore's base class does with no registered access policy, which in practice requires superuser status.

Expected behavior

A non-superuser granted the appropriate permission via a Role should be authorized, consistent with every other Pulp content plugin.

Environment

• pulpcore 3.105.7
• pulp-maven 0.12.0

Additional context

The identical gap exists in pulp_npm and pulp_hugging_face — none of the three define DEFAULT_ACCESS_POLICY on any viewset. Filing companion reports in each repo since root cause and fix (mirroring pulp_rpm/pulp_file's pattern) look identical across all three. Happy to test a patch if a maintainer can confirm the intended locked-role naming convention for maven.