darkhelm/notifications-api
1
0
Fork 0
mirror of https://github.com/GSA/notifications-api.git synced 2026-02-04 02:11:11 -05:00
Code Issues Packages Projects Releases Wiki Activity

Minor doc formatting and typo fixes

Browse Source 
Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
This commit is contained in:
Carlo Costino
2023-07-05 15:29:59 -04:00
parent 22670b6ee6
commit f93972e9c4
1 changed files with 31 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
docs/adrs/0005-agreement-data-model.md
View File

@@ -10,11 +10,18 @@
**OPEN ISSUE(S):** https://github.com/GSA/notifications-api/issues/141, https://github.com/GSA/notifications-admin/issues/53, https://github.com/GSA/notifications-admin/issues/51 **OPEN ISSUE(S):** https://github.com/GSA/notifications-api/issues/141, https://github.com/GSA/notifications-admin/issues/53, https://github.com/GSA/notifications-admin/issues/51
We will be entering into memoranda of understanding (MOU) and Interagency Agreements (IAA) with partner agencies. Data from those agreements will be important for application function. We will be entering into Memoranda of Understanding (MOU) and Interagency
Agreements (IAA) with partner agencies. Data from those agreements will be
important for application function.
Unlike the UK version of the application, users will not be able to complete a self-service in-app agreement process. Our agreement process requires that documents be “signed” outside of the application and (especially in the case of an IAA) needs to happen with specific forms that have historically proven difficult to automate. Unlike the UK version of the application, users will not be able to complete a
self-service in-app agreement process. Our agreement process requires that
documents be “signed” outside of the application and (especially in the case of
an IAA) needs to happen with specific forms that have historically proven
difficult to automate.
Inside the application, we’ll want to know information about the partner as well as information necessary to avoid overspending the account. Inside the application, we’ll want to know information about the partner as well
as information necessary to avoid overspending the account.
This information includes: This information includes:
- Agreement identifier - Agreement identifier
@@ -36,7 +43,7 @@ An implementation should address these needs:
- The ability to connect data to organization and service models - The ability to connect data to organization and service models
This is a minimal implementation of agreement data. It's quite possible that This is a minimal implementation of agreement data. It's quite possible that
it will change and expand over time, but those needs are note yet clear. it will change and expand over time, but those needs are not yet clear.
Because we will continue to have the actual agreement docs safely in Google Because we will continue to have the actual agreement docs safely in Google
Drive, this implementation does not need to be a source of truth and does not Drive, this implementation does not need to be a source of truth and does not
@@ -60,9 +67,9 @@ As a team, we've gone through the following options:
- Separates agreements from the orgs, since they may change separately - Separates agreements from the orgs, since they may change separately
- Multiple agreement-like models might be confusing, this avoids that - Multiple agreement-like models might be confusing, this avoids that
- Cons: - Cons:
- Groups IAA and MOU together, which makes validation at the model level harder - Groups IAA and MOU together, which makes validation at the model level
and, in turn, makes it easier to break validation logic elsewhere in the harder and, in turn, makes it easier to break validation logic elsewhere
application in the application
- Add MOU and IAA models: two new classes in `models.py` with the same fields - Add MOU and IAA models: two new classes in `models.py` with the same fields
but different configurations. but different configurations.
@@ -82,22 +89,27 @@ As a team, we've gone through the following options:
## CHOSEN OPTION: Add an Agreement model ## CHOSEN OPTION: Add an Agreement model
By adding an Agreement model, we’ll allow flexibility in the interaction between agreements and organizations but stop short of attempting to recreate the full complexity of agreements in our data model. By adding an Agreement model, we’ll allow flexibility in the interaction between
agreements and organizations but stop short of attempting to recreate the full
complexity of agreements in our data model.
If we later find that it’s necessary to separate MOU and IAA agreements, we should be able to perform a migration. If we later find that it’s necessary to separate MOU and IAA agreements, we
should be able to perform a migration.
### Consequences ### Consequences
- Positive - Positive
- We’ll gain more granular control over message limits for paid (IAA) agreements - We’ll gain more granular control over message limits for paid (IAA)
agreements
- We can offer more agreement transparency to users. For example, identifying - We can offer more agreement transparency to users. For example, identifying
agreements that will need renewal agreements that will need renewal
- Negative - Negative
- We’re adding some complexity to the data model - We’re adding some complexity to the data model
- We know that this implementation is an MVP and thus might have rough edges - We know that this implementation is an MVP and thus might have rough edges
- Manual work is necessary to keep agreements in sync with the real-world process - Manual work is necessary to keep agreements in sync with the real-world
process
## VALIDATION AND NEXT STEPS ## VALIDATION AND NEXT STEPS