Real-Dev-Squad / todo-action-items

A running list of todo items for Real Dev Squad site
MIT License
4 stars 8 forks source link

[RFC] for Improving Archiving User Functionality #179

Open gauravsinhaweb opened 10 months ago

gauravsinhaweb commented 10 months ago

Introduction

The existing process for archiving users involves sending a PATCH request to ${baseURL}/users/${rdsId}/temporary/data. This request triggers the execution of the validateUpdateRoles function in the backend, responsible for updating user roles based on provided boolean values.

async function validateUpdateRoles(req, res, next) {
  // Validation schema for the request body
  const schema = joi.object().strict().min(1).max(1).keys({
    member: joi.boolean(),
    archived: joi.boolean(),
  });

  try {
    await schema.validateAsync(req.body);
    next();
  } catch (error) {
    logger.error(`Error validating updateRoles query params: ${error}`);
    res.boom.badRequest("We only allow either role member or archive");
  }
}

The current process lacks the ability to capture the reason for archiving a user within the archiving process due to the primary focus on the "Update Roles" functionality.

Problem Statement

The challenge is to incorporate the user archiving reason into the existing process. Two potential solutions have been identified:

  1. Combining Reason with Roles The first approach involves adding the reason as a string to the request body. This would require sending both the archived status and the reason together:

    {
       "archived": true,
       "reason": "some string"
    }

    However, this approach conflicts with the existing validateUpdateRoles function, which is designed specifically to handle role-related updates. Thus, this method might not align well with the current architecture.

  2. Introducing a Separate API for Archive Logs The second approach suggests creating a separate API endpoint to handle the archival process, including capturing the user archiving reason. This new endpoint would be responsible for logging archive details such as the Reason. While this approach ensures a dedicated location for archiving-related information, it introduces the concern of potential performance impacts due to an additional API call during the archiving process.

Proposed Solution

To address the challenge of integrating the user archiving reason, I propose a hybrid solution that combines the strengths of both approaches:

Enhanced Archiving API Endpoint Create a modified version of the existing validateUpdateRoles function that not only validates role-related updates but also captures the archiving reason if provided. The request body would be extended to accommodate the reason field, making the process more versatile:

async function validateUserRequest(req, res, next) {
  const schema = joi.object().strict().min(1).max(2).keys({
    member: joi.boolean(),
    archived: joi.boolean(),
    reason: joi.string().when('archived', { is: true, then: joi.required() }),
  });

  try {
    await schema.validateAsync(req.body);
    next();
  } catch (error) {
    logger.error(`Error validating archiving request: ${error}`);
    res.boom.badRequest("Invalid archiving request");
  }
}

By introducing the validateUserRequest function, we maintain the original purpose of updating roles while accommodating the need to include a reason during the archiving process. This minimizes the need for an additional API call and maintains performance efficiency.

Feel free for suggestions/ comments

iamitprakash commented 10 months ago

@gauravsinhaweb solution 1 looks okay, still if you want to align function name, feel free to re-name with suitable one.

gauravsinhaweb commented 10 months ago

@gauravsinhaweb solution 1 looks okay, still if you want to align function name, feel free to re-name with suitable one.

Sure, will go forward with this approach Thanks!