DirectoryObjects: drop the publicKeyInfrastructureRoot tag from the module mapping (v2)
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 84/100
- Issue type
- Refactor
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- powershell
- Domain
- build-system, tooling
Research direction
Start in config/ModulesMapping.jsonc and src/DirectoryObjects/DirectoryObjects.md; compare the DirectoryObjects mapping with identity.DirectoryManagement and the v1.0 rows in MgCommandMetadata.json. Remove the v2 tag and 17 directives, then regenerate DirectoryObjects; done when the generated diff is empty apart from those directive removals.
Written by the indexing model from the issue text.
Description
While fixing a duplicate-generation problem in v3 (#3733), we found that the DirectoryObjects entry in config/ModulesMapping.jsonc on main still claimsdirectory.publicKeyInfrastructureRoot, but the module never actually ships that surface. The cmdlets get generated and then deleted again by 17 remove directives in src/DirectoryObjects/DirectoryObjects.md. The real owner is identity.DirectoryManagement - it has all 18 publicKeyInfrastructure files on main across v1.0 and beta, and every v1.0 row in MgCommandMetadata.json points there.
So today the tag just creates work that directives throw away, and the mapping says the wrong module owns the surface. v3 already removed the tag on its side; this issue is to do the same on v2, per the review discussion on #3733.
Suggested fix:
- Remove directory.publicKeyInfrastructureRoot from the DirectoryObjects entry in config/ModulesMapping.jsonc.
- Delete the 17 dead PublicKeyInfrastructure remove directives from src/DirectoryObjects/DirectoryObjects.md.
- Regenerate DirectoryObjects - the diff should be empty apart from the directives, which confirms the tag was producing nothing.
- Dominant language
- C#
- Stars
- 898
- Forks
- 230
- Avg merge
- 2d 5h
- Merged PRs (30d)
- 31
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoftgraph/msgraph-sdk-powershell
-
status:waiting-for-triage type:bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
status:waiting-for-triage type:bug
Difficulty 3/5 1-2 days Newbie friendliness 72/100
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
-
status:waiting-for-triage type:bug
Difficulty 4/5 3-5 days Newbie friendliness 45/100
-
status:waiting-for-triage type:bug
Difficulty 3/5 1-2 days Newbie friendliness 68/100
All issues in microsoftgraph/msgraph-sdk-powershell
Similar issues
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
Type: enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
apache/arrow-adbc#4809 ·
-
type/automation type/tech-debt
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
microsoft/vscode-azurefunctions#5197 · 1 comment ·
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
microsoft/microsoft-ui-reactor#1274 ·