From RPM Wiki
| Table of contents |
Summary
Improvements to field setup and rules. Currently part of the Saturn spec.
Terms
- Template designer - The interface for editing fields & workflow for a process template.
- All fields fall into one of two groups:
- Static fields: Line, Label, Description, and Link (fixed) fields.
- Dynamic fields: All other field types
- Another way of dividing the fields:
- Input fields: All dynamic fields except the calculated types
- Display fields: All other field types (static + calculated)
Security
Controls access to a field (hidden, etc.) as well as required fields (can't be left blank). A field has one of two security methods: individual, group.
Method
- Individual: The field has a default security rule and zero or more additional security rules.
- Group: The field shares security fields with other fields in a field group. The field group has a default and additional security rules in the same way a field with an individual method does.
Security rules
A security rule has 5 parts
- Users: Who is affected
- "Staff users", "Agent users", each role, "All users"
- Effect: How the field is presented to those users when the rule is true
- "Hidden", "Read only", "Read & edit", "Required"
- Scope: When is the rule true
- "Always", "Status", each dynamic field
- Operator: If the scope is not always
- "is", "is not", ">", "<" (available options depend on the field type)
- Value: If the scope is not always
- "n/a", (other available options depend on the field type)
Default rule
The default security rule only has an effect. The other 4 properties do not apply.
Example rules
- Staff users: Read & edit always
- Agent users: Required if status is New
- Default: Hidden
Conflicts
If one or more additional permission rules are in conflict use the resulting permission with the least security.
- Do not count the default rule in conflicts. In other words, the default rule is always ignored when another rule applies, regardless of the effect.
- Example: One rule says agent users can edit a field when the status is "New" and another says it's hidden from agent users if the date "Sent for review" is not null. So what happens when the status is new and that date is filled in? The field is hidden for agent users.
Effects & field type
- Display fields always treat Required and Read & edit as just Read only
- Input fields treat Required and Read & edit as just Read only when the fields are being displayed (in other words, not in edit mode)
Validation
Some types of fields are allowed to have an optional validation rule. This is a check that will be done when a user edits a value. It is not done on empty fields.
Date
- Must be
- Before
- After
- {other date field} or {value}
Money
- Must be
- Less than
- Greater than
- {other money field} or {value}
Text
- Uses a special notation
- n: 0 - 9
- a: a - z, A - Z
- ?: any character or null if at the end
- ( ) . , - {space}: the character shown
- Example, a phone number: "(nnn) nnn-nnnn"
- Example, a phone number may or may not have extension: "(nnn) nnn-nnnn?????????"
Conflicts
- The "Required" permission and any valid/invalid rules are only enforced if the field is editable by the user.
- Example: And agent user is editing a form and a field is required for agent users at the current status. However the field also belongs to a group that makes it hidden because of the value selected in another field. Since the field is hidden we don't enforce the required rule.
Default
Any input field may have a default value selected or entered.
- Default for new fields is "n/a" or empty
Status trigger
Any input field may have an optional status trigger rule. This means that when the field is filled in (and is valid, if applicable) the status of the form will be automaticaly changed.
Conflicts
If multiple fields are filled in with one edit that have different status triggers, advance to the latest (farthest down the list) status level.
Other rule ideas
- Include in form copy
- This page was last modified 18:45, 21 Mar 2008.
- This page has been accessed 3884 times.