Brivo Labs - SAM API Delegated Access Request Hook

Project Overview

BrivoLabs has a beta version of a node.js/coffeescript application that is called Social Access Management (SAM) API. It uses postgres database, runs on heroku, consists of both a web and a worker process, and uses a redis-based message queue to communicate between them.

Brivo Labs also have an smartphone app that allows invited guests to simply check in/out using a QR Code, A new feature of Randivoo that allows a Salesforce User to open a door remotely from Chatter. This uses a new feature of Chatter called "Action Links" which are basically configurable buttons embedded in a Chatter post. The action of those buttons is essentially some callback URL with configurable parameters.

Competition Task Overview

In this challenge we are updating SAM API to support the Chatter 'Action Link' new features in Randivoo app. The diagram below demonstrate the flow of the new feature.

Detailed Requirements

We need to extend Webhook concept in SAM API so that the callback URL from "Action Link" is a unique Webhook URL that expires after some period of time. To support the expiration concept, we are adding new model and endpoints and will update webHook controller to handle it.

What you need to implement in this challenge :

• Add new model, call it 'delegatedAccessRequest', it should have the following fields :
  • Id - a unique GUID
  • audit fields
  • Date field 'expirationDate' that represents the expiration date of webhook
  • Flag field 'status' to set status of the request : it is used as auditing for webHook status, it should have three status "Pending", "Denied", "Expired", and "Accepted".
  • JSON field 'properties' : It holds the "state" of the webhook which include the pointers to all the necessary SAM data (who, what, where). These information will be passed from Randivoo app, we don't need to manipulate these data, only store it as it is.
  • DomainAcount field 'creator' : association with domainAccount model represents the creator of the webhook (take it from req.user)
• Add four new endpoints to webHookController :
  • POST /delegatedAccessRequests - create delegatedAccessRequest record
    • properities and expirationDate are mandatory input to this endpoint.
    • the endpoint must be non-public, at requires at least 'super user' role.
    • audit fields will be set on create.
    • set creator to req.user.
    • set status field to "Pending".
    • response of the POST is created entity, in addition, return a constructed URL for the webhook. (i.e. http://api.brivolabs.com/webHook/delegatedAccessRequests/5228d98d35976ed772000029)
      • The URL template should be configurable.
  • PUT /webHook/delegatedAccessRequest/:id - update delegatedAccessRequest record
    • Method accepts a required input parameter 'status' with two possible values : accept or deny
    • Endpiont is public  : no authorization required.
    • Validate the record has not expired - if expired update 'status' field to 'Expired', and throw custom error.
    • if record has not expired, check status input parameter :
      • if 'accept' then update 'status' field to 'Accepted', wait for 5 seconds period (preferred to be configurable) then pulse the door.
      • if 'deny' then update 'status' field to 'Denied', and exist method without doing anything.
    • If entity does not exist - throw custom error
  • DELETE /delegatedAccessRequest/:id - remove delegatedAccessRequest record
    • method is non-public. it requires super user role
    • Only creator or admin in the same domain can delete ther record.
    • throw custom error if entity does not exist
  • GET /delegatedAccessRequest/:id - retrieve delegatedAccessRequest record
    • methos is not public, super user role is required
    • the method will simply return the delegatedAccessRequest entity
    • throw custom error if not found
• Use transaction in all methods that change db state.

General Notes

• Create custom errors following as in customErrors.coffee
• Update IO docs and postman documents to support new changes.
• All files changed and new must have class/method documentation and inline comments.
• The solution must work locally and on Heroku.
• Update readme for deployment (locally and heroku)

Testing

Create unit tests for new endpoints - it must follow the same testing standards we are using in existing tests.

Source Code

The API source code is provided in challenge forums. It include .git folder, use it to create patch file for deliverables.

Final Submission Guidelines

Deliverables

• Patch file of changes
• Text file with notes to reviewer.