Overview
Every user need to Accept the terms and conditions in order to access the portal:
- Case 1: Existing user, will be flagged with terms & conditions flag will be set to false.
- Case 2: Whenever a new user registers his terms & conditions flag will be set to false.
- Case 3: When the terms & conditions are changed - In this scenario we will get the accepted version of TAC from user and the latest version of TAC from systemSetting, if there is any difference in the version we will ask user to accept the TAC again.
After login, we will detect - if user needs to accept the terms of condition - in either of above cases, we will present him with screen to accept the same.
Applicability/configuration of terms and conditions will be based on chosen approach.
Assumption:
We do not propose to create API for creating/updating terms & conditions.
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 support terms & conditions - 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/user/tac/accept{ "request": {
} }
Notes: Version will be identified from System settings. system settings will have identifier as "tncConfiguration" that will hold terms and condition version and other details. User Id will be taken from "x-authenticated-user-token".
2. Get TAC
GET /v1/tac/read
Response
{
"response": {
"text":"html content",
"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
Response
200 OK - Terms updated successfully
400 Bad Request - Request validation - invalid userId or invalid tacVersion
We need to provide only accept TAC api. Terms and condition page will be hosted on portal and app will also use same html page. when ever terms and condition page change, user need to update the new terms and condition version under system settings table.