Page Comparison

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 TnC from user and the latest version of TAC TnC from systemSetting, if there is any difference in the version we will ask user to accept the TAC TnC 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.

...

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 designsWe need to provide only accept TnC 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.

Approach 1:

We can create terms & conditions - globally - i.e. per installation basis.

...

Solution based on Approach 2( Approach 1 is just a sub-set)

DB changes 

Table Added: tac

...

version of TAC

...

Approach

• Terms & Conditions will be stored as public html page on portal itself.
• Admin has to update the system settings table, whenever the TnC page and version is modified.

• After successful login - portal will call read user api.

• This api response will contain - a flag - based on which portal can redirect the user to Accept Term & Conditions page.
• The above flag will be calculated based on following two conditions
  • if tncversion is null in user table, for the logged in user, showTnC flag will be marked to true
  • if tncversion is not null and does not match with version stored in System Settings table, flag will be marked true
• API will also contain tncaccpteddate & tncversion - for information purpose only - it might get used in future, if we want to show it to the user.

DB changes 

Changes to user table

Note: columns tcstatus & tcupdateddate - will be removed as part of table clean-up - which are actually not being used

Storage in System Settings

We will add one system setting → tacVersions tncConfiguration, which will store the applicable tacVersions tncVersions per channel basis in following format.

Admin has to update the system settings table for applicable tacVersionchannel , for new tacVersion tncVersion to be impacted.

[
 {
  "channelName":"NameOfChannel 1",
  "tacVersiontncVersion": "tacVersionApplicablev2.0"
 },
 {
  "channelName":"NameOfChannel 2",
  "tacVersiontncVersion" : "tacVersionApplicablev1.0"
 }
]
Changes to existing API

GET /v1/user/read/:uid

→ Will add following keys to the response:

tacAcceptedshowTnC: true or false

tacAcceptedDatetncAcceptedDate: informational purpose

tacAcceptedVersiontncAcceptedVersion: informational purpose

→ tacAccepted → showTnC is true → user will not be prompted for terms & conditions acceptance page.

→ tacAccepted → showTnc is false → user will be propmted for terms & conditions acceptance page

APIs Added

1. Accept TAC  TnC 
   POST  /v1/user/tactnc/accept

   {
     "request": {
       
     }
   }

   
NotesNote: 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

...

        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 & conditions accepted 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 table401 Unauthorized  - In case user API is called without proper user-access token.