Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

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 NamePurpose
idPrimary key of the table, auto-generated
version

version of TAC

channelchannel-id
texthtml content
createdOncreated date 
createdByuser- who created it
lastUpdatedOnlast updated on
lastUpdatedByuser- who updated it

→ Admin will directly insert the record into this table, each time terms & conditions need to be updated.

Changes to user table

ColumnChanges
tacstatusAdded - boolean - true if terms ad condition is accepted
tacaccepteddateAdded - if tacstatus false → this will be null, else last time user accepted terms and conditions will be stored
tacversionidAdded - if tacstatus false → this will be null, else last version of accepted terms and conditions will be stored
tcstatusRemoved - as this is not used currently
tcupdateddateRemoved - 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

  1. Accept TAC  
    POST /v1/tac/accept
    {
  "request": {
        "version":"v1"
  }
}


     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



  • No labels