Feat: Account Deactivation by Platform Admin

[mukunzidd]

Description

As a platform admin, I want to be able to deactivate a user's account (vendor or buyer) for various reasons, such as policy violations, suspicious activities, or maintenance purposes. This feature will allow the admin to temporarily or permanently disable a user's access to the e-commerce platform.

Acceptance Criteria

• Implement an API endpoint for account deactivation by admin
• Validate admin's authentication and authorization
• Deactivate the user's account by updating the database
• Revoke any active sessions or access tokens for the deactivated account
• Implement appropriate error handling and responses
• Implement input sanitization

Developer Notes

• Define the API endpoint and request/response payloads for account deactivation
• Implement authentication and authorization checks for admin access
• Update the user account status in the database to indicate deactivation
• Revoke any active sessions or access tokens associated with the deactivated account
• Handle edge cases, such as failed deactivation or unauthorized access
• Write unit tests to cover different scenarios and edge cases
• Write clear API documentation for the resulting endpoint

Related Issues

• #xx related issue title

Definition of Done

• Account deactivation API endpoint is implemented and functional
• Admin authentication and authorization are validated
• User accounts are deactivated by updating the database
• Active sessions or access tokens for deactivated accounts are revoked
• Appropriate error handling and responses are implemented
• Input sanitization measures are in place
• Unit tests are written and passing
• Code adheres to coding standards and best practices
• API documentation for the resulting endpoint is completed

[ambroisegithub]

Implementation Plan on Account Deactivation by Platform Admin

Deliverables:

• API endpoint for account deactivation by admin.
• Validation of admin's authentication and authorization.
• Deactivation of user accounts in the database.
• Revocation of active sessions or access tokens for deactivated accounts.
• Implementation of error handling and responses.
• Input sanitization measures.

Data Flow / Flowchart / Pseudocode / ERD Diagrams:

Flowchart illustrating the data flow and operations involved in account deactivation.
ERD diagram showing the database schema for user accounts and related information.

Start:

• The request enters the system.
• IsLoggedIn Middleware: Checks if the user is logged in by verifying the JWT token.
• If the user is not logged in, it returns a 401 Unauthorized response.
• If the user is logged in, it continues to the next step.

checkRole Middleware:

• Checks if the user has the necessary role to perform the action.
• If the user doesn't have the required role, it returns a 403 Forbidden response.
• If the user has the required role, it continues to the next step.

Route for Deactivating Account:

• Receives a PUT request to deactivate an account.

• Calls the deactivateAccount controller function.

deactivateAccount Controller:

• Parses the userId from the request parameters.
• Finds the user in the database by userId.
• If the user is not found, returns a 404 User Not Found response.
• If the user is already inactive, returns a 400 User Already Inactive response.
• Changes the user's status to 'inactive' and saves the changes.
• Returns a 200 Success response with a message indicating successful deactivation.

Route for Activating Account:

• Receives a PUT request to activate an account.
• Calls the activateAccount controller function.
• activateAccount Controller:
• Parses the userId from the request parameters.
• Finds the user in the database by userId.
• If the user is not found, returns a 404 User Not Found response.
• If the user is already active, returns a 400 User Already Active response.
• Changes the user's status to 'active' and saves the changes.
• Returns a 200 Success response with a message indicating successful activation.

End:

The response is sent back to the client.

Schedule of Implementation:

Day 1 (wednsday):

• Define API endpoint and request/response payloads.
• Implement authentication and authorization checks for admin access.

Day 2 (Thursday):

• Update user account status in the database to indicate deactivation.
• Revoke any active sessions or access tokens associated with deactivated accounts.

Day 3 (Friday-Morning):

• Handle edge cases, such as failed deactivation or unauthorized access.
• Implement error handling and responses.

Day 3 (Friday-afternoon):

• Implement input sanitization measures.

Write unit tests to cover different scenarios and edge cases.

Day 3 Friday-afterNoon-evening:

• Ensure adherence to coding standards and best practices.
• Complete API documentation for the resulting endpoint.

Additional Notes:

• Regular reviews and testing to identify and address issues promptly.
• Collaboration with team members for integration and feedback.
• Clear communication channels for updates and feedback.
• Allocate time for unexpected challenges or additional requirements.
• Utilize external services or libraries as needed for authentication, database management, etc.

External services or libraries to be used:

• Frameworks like Express.js for building APIs.
• Passport.js for authentication.
• TYPEORM.
• Jest for unit testing.
• Swagger for API documentation.