feat(generated): Authorization (batch c64ce1e7)

[workos-sdk-automation]

Summary

Regenerated SDK from spec changes.

Triggered by workos/openapi-spec@e2873c2

[greptile-apps]

Confidence Score: 4/5

The PR is not safe to merge until existing two-argument calls to the public constructor remain valid.

Findings

1.  Required group argument breaks callers ▶
2.  Group assignments lack test coverage ▶

Fix with agent prompt

### Issue 1
lib/Resource/UserRoleAssignmentSource.php:20
If a consumer constructs `UserRoleAssignmentSource` with the previously valid two arguments, the new `$group` parameter is required even when there is no group. Upgrading will cause that call to throw an `ArgumentCountError`. Defaulting the nullable parameter to `null` would preserve those calls.

```suggestion
        public ?UserRoleAssignmentSourceGroup $group = null,
```

### Issue 2
tests/Fixtures/list_user_role_assignment.json:18
The assignment fixtures contain only `"group": null`, and no test uses the new fixture with a non-null group. Add a group-derived assignment case that checks decoding and serialization through `UserRoleAssignmentSource`; otherwise a regression in the new nested-group path could pass the test suite.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

The PR adds a group model to user role assignment sources and regenerates the corresponding fixtures and metadata.

• Existing direct-assignment responses remain supported.
• The new constructor argument breaks existing two-argument construction, and the group-derived response path lacks test coverage.

_{Reviews (1) · Last reviewed commit: "chore(generated): add release notes frag..."}

[greptile-apps]

Required group argument breaks callers

If a consumer constructs UserRoleAssignmentSource with the previously valid two arguments, the new $group parameter is required even when there is no group. Upgrading will cause that call to throw an ArgumentCountError. Defaulting the nullable parameter to null would preserve those calls.

Suggested change

	public ?UserRoleAssignmentSourceGroup $group,
	public ?UserRoleAssignmentSourceGroup $group = null,

Prompt To Fix With AI

This is a comment left during a code review.
Path: lib/Resource/UserRoleAssignmentSource.php
Line: 20

Comment:
**Required group argument breaks callers**

If a consumer constructs `UserRoleAssignmentSource` with the previously valid two arguments, the new `$group` parameter is required even when there is no group. Upgrading will cause that call to throw an `ArgumentCountError`. Defaulting the nullable parameter to `null` would preserve those calls.

```suggestion
        public ?UserRoleAssignmentSourceGroup $group = null,
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Group assignments lack test coverage

The assignment fixtures contain only "group": null, and no test uses the new fixture with a non-null group. Add a group-derived assignment case that checks decoding and serialization through UserRoleAssignmentSource; otherwise a regression in the new nested-group path could pass the test suite.

Prompt To Fix With AI

This is a comment left during a code review.
Path: tests/Fixtures/list_user_role_assignment.json
Line: 18

Comment:
**Group assignments lack test coverage**

The assignment fixtures contain only `"group": null`, and no test uses the new fixture with a non-null group. Add a group-derived assignment case that checks decoding and serialization through `UserRoleAssignmentSource`; otherwise a regression in the new nested-group path could pass the test suite.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!