Dynamic noun for an agreement's third party

[jonnalley]

User Story

As an OPRE staff member, I want the accepted language to describe an outside entity associated with an agreement so that ambiguity and uncertainty is further reduced when using OPS.

Acceptance Criteria

• [ ] When creating an agreement, the outside third party to OPRE that the agreement is associated with should be shown to the user with a different name/label based on the agreement type
• [ ] When the selected agreement type is changed to a Grant, the label shown to the user should dynamically update to "Grantee"
• [ ] When the selected agreement type is changed to an IAA, the label shown to the user should dynamically update to "Trading Partner" or accepted IAA language. Not all IAAs use the same language.
• [ ] When the selected agreement type is changed to an Contract, the label shown to the user should dynamically
• [ ] Direct obligation ?

---

Tasks

• [ ] Update backend model and logic as necessary
• [ ] Update frontend component behavior
• [ ] Update tests to include seeing correct names for the relevant agreement types

Definition of Done Checklist

• [ ] Usability validated
• [ ] UI works as designed
• [ ] OESA: Code refactored for clarity
• [ ] OESA: Dependency rules followed
• [ ] Automated unit tests updated and passed
• [ ] Automated integration tests updated and passed
• [ ] Automated quality tests updated and passed
• [ ] Automated load tests updated and passed
• [ ] Automated a11y tests updated and passed
• [ ] Automated security tests updated and passed
• [ ] 90%+ Code coverage achieved
• [ ] PR(s) have been merged to main
• [ ] Design/tech debt eliminated
• [ ] Build process updated
• [ ] Documentation updated or added
• [ ] Feature flags/toggles created

Additional Context & Resources

• 775

[jonnalley]

Is user research needed to see if a common term would be preferred over changing field names? or would it be better to adapt as the story reads?

[jonnalley]

@kimschulke @andressacurvelo reminder for us that if we end up abandoning a generic singular "create agreement" interface this story will presumably be moot ?

[kimschulke]

yes, if we change to a unique workflow for each agreement type, every aspect of that flow could be more customized to the agreement type including the "partner" phrasing differences - good to note for future consideration!