Feature: Component Based Rule Settings

[mialy-defelice]

Component Based Rule Setting

Component-Based Rule Setting is a powerful feature in data modeling that enables users to create rules tailored to specific subsets of components or manifests. This functionality was developed to address scenarios where a data modeler needs to enforce uniqueness for certain attribute values within one manifest while allowing non-uniqueness in another.

Here's how it works:

• Rule Definition at Attribute Level: Rules are defined at the attribute level within the data model.
• Manifest-Level Referencing: These rules can then be applied (or not) to specific manifests within the data model. This means that rules can be selectively enforced based on the manifest they're associated with.

This feature offers flexibility and applicability beyond its original use case. The new Component-Based Rule Setting feature provides users with the following options:

Apply a Rule to All Manifests Except Specified Ones: Users can now define a rule that applies to all manifests within the data model except for those explicitly specified. In cases where exceptions are specified, users have the flexibility to define unique rules for these exceptions or opt not to apply any rule at all.

Specify a Rule for a Single Manifest: Alternatively, users can specify a rule that applies to a single manifest exclusively. This allows for fine-grained control over rule enforcement at the manifest level.

Unique Rules for Each Manifest: Users can also define unique rules for each individual manifest within the data model. This enables tailored rule enforcement based on the specific requirements and characteristics of each manifest.

By leveraging the enhanced Component-Based Rule Setting feature, data modelers can efficiently enforce rules across their data models with greater precision and flexibility, ensuring data integrity while accommodating diverse use cases and requirements.

Note: All restrictions to rule combos and implementation also apply to component based rules.

As always try the rule combos with mock data to ensure they are working as intended before using in production.

Format:

• ^^Double carrots indicates that Component based rules are being set
• Use ^^ to separate component rule sets
• `# In the first position (prior to the rule) to define the component/manifest to apply the rule to
• # character cannot be used with out the ^^` to indicate component rule sets

Use case:

• Apply rule to all manifests except specified set.
  • validation_rule^^#ComponentA
  • validation_rule^^#ComponentA^^#ComponentB
• Apply a unique rule to each manifest.
  • #ComponentA validation_rule_1^^#ComponentB validation_rule_2^^#ComponentC validation_rule_3
• For specified manifest apply given validation rule, but for all others run a different rule
  • #ComponentA validation_rule_1^^validation_rule_2
  • validation_rule_2^^#ComponentA validation_rule_1
• Apply validation rule to only one manifest
  • #ComponentA validation_rule_1^^

Testing

Testing Resources

Test Models:
TBD

Test Manifest:
Example Biospecimen Manifest

Example Patient Manifest

Testing Steps:

TBD

[mialy-defelice]

@andrewelamb @GiaJordan I added an additional check for duplicate components in a rule, and updated the testing.

[sonarqubecloud]

Quality Gate passed

Issues
43 New issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud