Challenge Overview

Project Overview

The client for this project has decided to build a platform that will support the sale, exchange, and redemption of gift cards between businesses and individuals.  The goal of this platform is to help small businesses expand, using both web and mobile layouts, by giving them a simple way to raise capital and acquire new customers using gift cards.

The client needs to create a high quality platform that is easy-to-use even for business owners that don’t have a lot of technical expertise.  Many business owners are not technologically sophisticated, so creating a platform that is simple to understand and navigate is also a top priority.

The main function of the platform will be to allow business to post virtual gift cards for sale on the platform.  Individual users will be able to browse and buy these gift cards, as well as resell or trade gift cards they own.  Using the mobile layout, users will be able to redeem their gift cards at the business, and the business will be able to process gift card redemption at their point of sale.

Time constraint
This project has tight time line so
1) the review phase is only 24 hours
2) we would like to avoid any timeline extension, please ask questions early

 

Task overview

 

This assembly is responsible for making the following improvements in the provided codebase (attached). Both FE and BE architectures are attached for reference.

 

1. Fix input validation in back-end methods. There must be consistency of data type and length (e.g. strings must be limited to 1024 chars, except for rich text fields which may be up to 16K). For "range" field the range start must not be greater than the range end. Most of business parameters must be non-negative.


2. Fix permission check in the front-end controllers. For example: in PUT /businesses/me/employees/:id you can enter any :id and update any user. You can update any field in req.body. For example you can update the email address and reset password for that user. You will get a reset password link to your updated email, so you can hack this account.

Such a vulnerability must be fixed. See the architect's solution for it below.

The business admin can add/update the business employee, in current design, the admin can update any employee email and password, this need be updated, we only allow the admin can update his/her own business employees, we can define following method in BusinessController:

+checkPermission(req: Request, userId:String, callback:function):void

Parameters:

- req : the request

- userId: the id of user who will be updated or deleted

- callback : the callback function

Implementation:

1)  Get current user from session:  currentUser = req.user

2)  iterate current user role via currentUser.userRoles

3) Get the businessId if there is a role is BUSINESS_ADMIN

4) Get the user info via UserService.get(userId)

5) check the returned user have a user role with {businessId: the businessId in step 3,   role: BUSINESS_EMPLOYEE}

6) if found,  callback(null, true);  else callback(new Error('you are not permitted');

BusinessController#deleteBusinessEmployee and BusinessController#updateBusinessEmployee need to call checkPermission firstly.

The following use cases must also be considered:
For Business, get/add/delete/update business employee should be only allowed by the business admin. 
For GiftCardOffer, create/delete/update/cancel should be allowed by the business employee or admin of that business, get/search GiftCardOffer are public.
For GiftCard, search/get/purchase giftcard are public, resell/prepareForRedeem giftcard should be owner of the giftcard, redeem should be  business employee or admin of the business of the gift card. get/add comment is public, delete comment should be the business employee or admin.

 

3. Create unit tests + code coverage for the existing code.


4. Fix documentation (now it's missing in many places and it's not consistent) as per TopCoder standards and the provided module architectures.

 

5. Currently some sensitive data is logged. The logging configuration must be reset so that no crendetials and payment details (e.g. credit card data) are logged any longer.

 

6. All operations that increase/decrease something (e.g. availableQuantity) must become atomic. Currently, you can make parallel requests and purchase single item more than availableQuantity which a major flaw. Mongodb supports atomic operations.

 

7. Code naming updates:

  • BusinessService#getByAccountId -> BusinessService#getByBraintreeAccountId
  • Business#Verify -> Business#PayForVerification

(all client’s code in both back-end and front-end must be updated for both items above)

 

8. User’s files storage. Profile images/business logo and other assets uploaded by users must be stored in the file system (as opposed to the database). For the sake of scalability the file system will be implemented with AWS S3 bucket.

The current code is inconsistent in this regard:

- in create user logic, profile image / business profile is saved in file system.

- in modify user logic, the profile image is saved in mongondb

- there is no code to retrieve and show the profile image after create/modify.

So your task to update the code so that all the images are stored in the file system and relevant DB fields stores URI to a file. For reference see http://www.bucketexplorer.com/documentation/amazon-s3--how-to-generate-url-for-amazon-s3-files.html Signed url section about how to get url from S3.

9. Business ID.

Backend API expects us to submit a businessId when we register. We don't submit it in the mobile app and API creates a userRole with empty businessId.

This is wrong, because we should create a new Business record and associated it with new created user. So this shall be fixed here.

 

10. Provide updated postman.json file.

 

11. Implement error handling in services/controllers.

 

12. Revamp profile history auditing in the back-end controllers using ActionRecordService and ActionRecord entity.

ActionRecord is an item of individual/business’s history shown at Profile->MyHistory page. This is a kind of audit.
REST API controllers at the backend will be responsible to call ActionRecordService to keep audit records (as per the system architecture). It was omitted at the level of Backend architect because audit requirement was postponed, however, during UI prototypes it partially returned as profile history.
E.g. GiftCardController#purchaseGiftCards must call this service to create an ActionRecord when user purchases a gift card but does not.
The use cases are:
 - gift card purchase
 - gift card resale
 - gift card redemption

The use cases are:

 - gift card purchase

 - gift card resale

 - gift card redemption

 

13. Some other misc issues must be brought up to the forum or via "Contact managers" and be fixed.

E.g. in /helpers/helper.js

// Global variable to store user coordinate for each request

var userCoordinates = null;

var isGiftCardFlag = true;

We shouldn't store user state in global variables, because it won't work correct if there are parallel requests.

 

14. If a business is updated, all its associated GiftCards and GiftCardOffers should be changed automatically.

 

 



Final Submission Guidelines

A complete list of deliverables can be found in the TopCoder Assembly competition Tutorial at:

http://apps.topcoder.com/wiki/display/tc/Assembly+Competition+Tutorials

You are to provide the Improved revamped working codebase as per the requirements and the deployment guide (if any updates there).

ELIGIBLE EVENTS:

2015 topcoder Open

REVIEW STYLE:

Final Review:

Community Review Board

Approval:

User Sign-Off

SHARE:

ID: 30049493