...
Applicability/configuration of terms and conditions will be based on chosen approach.
...
Assumption:
We can create do not propose to create API for creating/updating terms & conditions per channel basis.
In this case - we just need one more column - which stores the channel for which terms and conditions is applicable.
When user updates the terms and condition
- a new row will be inserted with content as well as date/user/status/channel
- old row status will be marked to false for the given channel
- flag in user table for terms & conditions will be marked to false based on channel value.
API
POST /v1/update/terms
{
"request": {
"termsAndConditions": "<html> content</html>",
"channel": "channel-id"
}
}Response
200 OK - Terms updated successfully
400 Bad Request - Request validation - empty Terms And Conditions
403 Forbidden - if user is not org admin
POST /v1/accept/terms
Empty Request bodyResponse
200 OK - Success
401 Unauthorized - Unauthorized access.
If called without user-token
Initial set-up needs to be done by inserting records into the relevant table, as per the below designs.
Approach 1:
We can create terms & conditions - globally - i.e. per installation basis.
Approach 2:
We can create support terms & conditions manually and inserts the version information in system settings.
When user updates the terms and condition
- A new row will be inserted in the TAC table
- We have to update the latest version of tac in system setting table
DB changes
...
- per channel basis - i.e. Each channel can have a different terms and conditions.
We recommend Approach 2 - so that within same installation - different organizations, have the flexibility to update terms & conditions of their own.
Solution based on Approach 2( Approach 1 is just a sub-set)
DB changes
Table Added: tac
| Column Name | Purpose |
|---|---|
| id | Primary key of the table, auto-generated |
| version | version of TAC |
| channel | channel-id |
| text | html content |
| createdOn | created date |
| createdBy | user- who created it |
| lastUpdatedOn | last updated on |
| lastUpdatedBy | user- who updated it |
...
→ Admin will directly insert the record into this table, each time terms & conditions need to be updated.
Changes to user table
| Column | Changes |
|---|---|
| tacstatus | Added - boolean - true if terms ad condition is accepted |
| tacaccepteddate | Added - if tacstatus false → this will be null, else last time user accepted terms and conditions will be stored |
| tacversionid | Added - if tacstatus false → this will be null, else last version of accepted terms and conditions will be stored |
| tcstatus | Removed - as this is not used currently |
| tcupdateddate | Removed - as this is not used currently |
Storage in System Settings
We will add one system setting → tacVersions, which will store the applicable tacVersions per channel basis in following format.
Admin has to update the system settings table for applicable tacVersion, for new tacVersion to be impacted.
[
{
"channelName":"NameOfChannel 1",
"tacVersion": "tacVersionApplicable"
},
{
"channelName":"NameOfChannel 2",
"tacVersion" : "tacVersionApplicable"
}
]
Changes to existing API
GET /v1/user/read/:uid
→ Will add following keys to the response:
tacAccepted: true or false
tacAcceptedDate: informational purpose
tacAcceptedVersion: informational purpose
→ tacAccepted is true → user will not be prompted for terms & conditions acceptance page.
→ tacAccepted is false → user will be propmted for terms & conditions acceptance page
APIs Added
- Accept TAC
POST /v1/tac/accepts/accept{ "request": {
"version":"v1" } }
...
For fetching TAC we will get the current version of the TAC from system setting and then fetch the particular TAC from table
ResponseResponse
200 OK - Terms updated successfully
...