fix(docs): autogenerate docs by mo-auto · Pull Request #12656 · JanssenProject/jans (original) (raw)

4797-4803: OAuth2 scope addition looks good.

Both hunks consistently add par scope to support Pushed Authorization Request flows. Nice addition!

Also applies to: 17053-17059

16584-16593: New parScriptDns array property added cleanly.

The addition of parScriptDns (Pushed Authorization Request script DNS identifiers) looks solid. Schema definition is correct (array of strings).

Verify that parScriptDns is consistently added across all related schemas mentioned in the changes (Client, Scope, CustomScript per the summary).

17085-17097: locationPath property addition looks good.

New string property for CustomScript schema. Clean and straightforward.

17726-17730: logoutStatusJwt boolean property added cleanly.

New property for TokenEntity schema. Properly typed and documented.

14950-14967: No duplication here—intentional permission hierarchy, friend!

Listen up! I dug into this and the pigeon wisdom says these ain't duplicates at all. The schema JansAttribute has a legit granular permission model built right in. You've got three permission levels (Access, View, Edit) applied across three roles (admin, user, whitePagesCanView). That's a proper role-based access control matrix, not bloat.

When I see adminCanAccess sitting next to adminCanView and adminCanEdit, they're doing different jobs—not the same thing listed twice. Same deal with the user permissions. The data examples throughout the file (lines 1274-1277, 1307-1310, etc.) confirm all six properties live together intentionally.

No incomplete migration here—this is solid semantic design. The original concern misread similar naming as accidental duplication.

Likely an incorrect or invalid review comment.

14950-14967: You better think twice here, friend! 🐦 I found something interesting: these seven properties (adminCanAccess, userCanAccess, whitePagesCanView, adminCanView, adminCanEdit, userCanView, userCanEdit) don't exist in the JansAttribute Java model, BUT they DO show up in actual API examples, the Terraform provider, and documentation.

This suggests they're being added by a serialization or mapping layer that I can't locate through static code analysis. The schema IS auto-generated correctly (YAML syntax is valid ✓), but I cannot definitively determine whether these properties are:

1. Legitimately computed/mapped by the API layer
2. Orphaned from an old refactoring

Run a manual verification: Check your API layer's serialization/mapping code (custom serializers, DTOs, or response builders) to confirm these 7 properties are intentionally added and remain current with your business logic.