-
Notifications
You must be signed in to change notification settings - Fork 49
Conversation
Issue being fixed or feature implemented
User story
Imagine you're creating a comment on your own blog post. After this ships, users will be able to set up document types that let anyone in a specific group create content--so communities, teams, or roles can contribute without handing full ownership to a single identity, while outsiders are blocked. In practice, that means you can launch things like shared collections, group-managed listings, or collaborative feeds where membership is the key to participating, and the platform will reliably honor that rule everywhere.
Technical description
Add support for creationRestrictionMode = 3 (Any group member) with a group index, including schema validation, DPP parsing/modeling (DocumentTypeV2), Drive/ABCI enforcement, and test coverage. Also align the Swift example app UI/logic to recognize the new mode.
What was done?
- Schema: added mode 3 and creationRestrictionGroup to document-meta.json with conditional validation.
- DPP:
- Added CreationRestrictionMode::AnyGroupMember.
- Introduced DocumentTypeV2 with creation_restriction_group and accessors.
- Implemented try_from_schema v2 to parse/validate group for mode 3 and forbid it otherwise.
- Added group-position validation during data contract create/update basic-structure checks.
- Added/updated random document type generator support.
- Platform versions:
- Added CONTRACT_VERSIONS_V4 (try_from_schema v2) and wired into PLATFORM_V12.
- Drive/ABCI:
- Enforced group membership for document creation when mode is 3.
- Added consensus errors for missing group position and non-members.
- Tests & fixtures:
- Added DPP unit tests for the new validation.
- Added Drive ABCI document creation tests (member success, non-member failure, missing group failure).
- Added contract fixture with group and mode 3.
- Swift example app:
- Parse/store creationRestrictionGroup.
- Adjusted creation filtering to allow mode 3 (exclude only mode 2).
- Updated creation restriction UI display and hints.
How Has This Been Tested?
Added unit tests.
Tested manually with dash-evo-tool
Breaking Changes
None
Checklist:
- I have performed a self-review of my own code
- I have commented my code, particularly in hard-to-understand areas
- I have added or updated relevant unit/integration/functional/e2e tests
- I have added "!" to the title and described breaking changes in the corresponding section if my code contains any
- I have made corresponding changes to the documentation if needed
For repository code-owners and collaborators only
- I have assigned this pull request to a milestone
Summary by CodeRabbit
-
New Features
- Documents can be restricted to "Any group member" via a new creation mode (value 3) and an associated group index.
- Creation now enforces group membership: only members of the specified group can create documents.
-
Chores
- Platform contract/version support updated to recognize the new document type version and schema changes.
-
Tests
- Added tests covering group-restricted creation success/failure and schema validation.
Tip: You can customize this high-level summary in your review settings.
WalkthroughWalkthroughAdds support for creationRestrictionMode = 3 ("Any group member") with an optional creationRestrictionGroup index across schema, DocumentTypeV2, validation, tests, and platform-versioning; enforces presence/absence of the group index and checks group membership during document creation. Changes
Sequence Diagram
sequenceDiagram
participant Client participant Validator as Validator (Document Create) participant DocType as DocumentType V2 participant Contract as Data Contract participant Group as Group Client->>Validator: Submit CreateDocument(owner_id) Validator->>DocType: creation_restriction_mode() DocType-->>Validator: AnyGroupMember (3) Validator->>DocType: creation_restriction_group() DocType-->>Validator: group_position Validator->>Contract: resolve_group_at_position(group_position) alt group exists Contract-->>Validator: Group ref Validator->>Group: member_power(owner_id) alt member_power > 0 Group-->>Validator: member_power > 0 Validator-->>Client: success (creation allowed) else not member Group-->>Validator: GroupMemberNotFound / ProtocolError Validator-->>Client: IdentityNotMemberOfGroupError end else position invalid Contract-->>Validator: not found Validator-->>Client: GroupPositionDoesNotExistError end Estimated code review effort4 (Complex) | ~45 minutes Poem
Pre-merge checks | 2 | 1Failed checks (1 warning)
Passed checks (2 passed)
Tip: You can configure your own custom pre-merge checks in the settings. Finishing touches
Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 3
Fix all issues with AI agents
In `@packages/rs-drive-abci/tests/strategy_tests/test_cases/address_tests.rs`:
- Around line 3523-3524: Rename the test function
run_chain_high_throughput_address_operations so its identifier begins with
"should" to comply with the tests naming convention; update the function
declaration #[stack_size(4 * 1024 * 1024)] fn
run_chain_high_throughput_address_operations() to a descriptive name starting
with "should", e.g. #[stack_size(4 * 1024 * 1024)] fn
should_run_chain_high_throughput_address_operations(), and update any references
to this function in the test module accordingly (keep the stack_size attribute
and body unchanged).
In
`@packages/rs-drive-abci/tests/strategy_tests/test_cases/identity_and_document_tests.rs`:
- Around line 670-672: Rename the test function
run_chain_insert_one_new_identity_per_block_and_one_new_document to start with
"should" (e.g., should_insert_one_new_identity_per_block_and_one_new_document)
while preserving the #[test] and #[stack_size(4 * 1024 * 1024)] attributes and
any references; update any references or uses of the function name in the test
module so the new name compiles and continues to run under the same test
harness.
- Around line 760-762: The test function
run_chain_insert_one_new_identity_per_block_and_a_document_with_epoch_change
should be renamed to follow the convention starting with "should"; update the
test function name (the #[test] function
run_chain_insert_one_new_identity_per_block_and_a_document_with_epoch_change) to
a descriptive name beginning with "should" (e.g.,
should_insert_one_new_identity_per_block_and_document_with_epoch_change) and
update any references to that symbol in the test module; keep the
#[stack_size(...)] attribute and function body unchanged.
Nitpick comments (3)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/data_contract_update/basic_structure/v0/mod.rs (1)
72-100: Consider using a named constant or theCreationRestrictionModeenum instead of magic number3.The value
3representsAnyGroupMembermode but is unclear without context. TheCreationRestrictionModeenum exists in thedppcrate and is already available through your imports. UsingCreationRestrictionMode::AnyGroupMember as u8or defining a constant would improve readability and prevent silent breakage if the enum values change. The same pattern appears indata_contract_create/basic_structure/v0/mod.rsat line 86.TODO.md (1)
15-26: TODO items reference V0/V1, but implementation uses V2.The tracking items suggest adding
creation_restriction_grouptoDocumentTypeV0andDocumentTypeV1, but based on the PR changes, the field is only being added to the newDocumentTypeV2. Consider updating the TODO to reflect the actual implementation approach (V2-only) to avoid confusion.packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/data_contract_create/basic_structure/v0/mod.rs (1)
328-385: Align the test name with the exercised scenario (nonexistent group).
The test setscreationRestrictionGroup: 1, so it validates a missing group position, not a missing field. Consider renaming and optionally adding a separate test that omits the field to exercise the "required" path.Rename suggestion
- fn should_return_invalid_result_when_creation_restriction_group _missing() {
+ fn should_return_invalid_result_when_creation_restriction_group _does_not_exist() {
packages/rs-drive-abci/tests/strategy_tests/test_cases/identity_and_document_tests.rs
Show resolved
Hide resolved
packages/rs-drive-abci/tests/strategy_tests/test_cases/identity_and_document_tests.rs
Show resolved
Hide resolved
|
Curious if you also plan to expand this to:
|