Schema for this entity is as follows:

- featureFlag
  + name [String] <Unique>
  + title [String]
  + id [String] <Unique>
  + created_at [Timestamp]
  + updated_at [Timestamp]
  + config [Object]
    - enabled [Boolean]
  + owner [String] (Unique identifier for user)
  + launched_at [Timestamp]

• Add the schema in the data-models repo.

These are the routes required for CRUD over this entity.

• Write Create featureFlag route.
• Write Update featureFlag route.
• Write Delete featureFlag route.
• Write a GET featureFlag route.
  • This returns all the feature flags for now.

The dashboard work is blocked on the create route and GET route, so we should finalize that part and the rest can be done async.

API contract to be validated according to the code in backend, currently there are few routes out of sync

Right now when we try to get tasks through the GET /tasks API we get all of them regardless of what is the status of them.
So we need to add a query param status to our endpoint so that we can filter the data based on the status of the tasks on the backend only and then use it in any manner we would like to do so.

API Endpoint: https://api.realdevsquad.com/users/picture

• User Login API
• User Details API
• User Update Details API
• Send SMS API
• Send WhatsApp messages API

Update User API contract to add new field:

• discordId as string (required)

Summary

The API that deals with updating the Archived role to true if the user is not in our discord was put under the PATCH /users endpoint with a request body differentiating it from the previous API that exists for the same route.

But, this API is not following the best API naming convention as it is not representing the resources it is modifying correctly.

This RFC aims at finding the API name that follows a better API naming convention.

Description

We have created a new API that will mark all the users Archived that are not in our discord i.e. set the archived=true for users that have in_discord=false.

Initially, the API name was PATCH /users/update-archived. As this is not correct because the verb is defined by the action PATCH so adding update in the endpoint is not correct.

Then, possible route names are proposed.

1. PATCH /users/archived
2. PATCH /users/archivedUsers

As in these routes archived is not representing a resource another solution proposed was,

Put the API under PATCH /users by defining the proper body. This is the current implementation.

Here is the API contact: https://github.com/Real-Dev-Squad/website-api-contracts/tree/main/users#patch-users

Requirement

Add API contracts for question and answers feature in live-site.

assignee and title queries are missing in queries details for GET /tasks request.

Relates to task for #1

This is to extend the ability of the GET /tasks API from the backend to also support filtering by parameters passed as queries.
The functioning would be as follows:-

1. If no query parameters passed i.e limit or offset then the response will get all the tasks there are in the database or default to a no. of documents to return.
2. If query parameters limit and offset is passed then it would return all the documents which are created after the created time of the <task_object> whose id = offset, plus would only return n no. of documents where n = limit and therefore would also work as a paginated API.

Parent Story

Real-Dev-Squad/website-www#343

Detailed requirements

Requirement document

Overview

This PR provides API contracts for live site - Real-Dev-Squad/website-www#343 and Real-Dev-Squad/website-www#427.

Create API contracts for upcoming task request feature

Links

Backend PR
Issue

remove POST/save, POST/purchase api contracts

POST/send / POST/request ->

1. take params as body
2. make params as none
3. have meaningful success message (eg. ${amout} credited/debited to ${user})

GET/transactions ->

1. make userid as param and limit as query
2. make body as the success response

GET/userinfo ->

1. make userid as param
2. body as success response

Parent Story

Real-Dev-Squad/website-www#343

Detailed requirements

Requirement document

Overview

Below APIs require documentation as per the 2nd release cycle of live site with moderator controls & kickout feature.

New APIs:

After running the Real-Dev-Squad/website-backend#1227, we will be removing token field.
Update the Users API contract to remove token field from it.

Currently the README.md is missing some of the links of the API contracts. There are more folders (contracts) than there are number of links/titles in the README

The ones marked in red are missing from the main README.md of this repo:

We need to add those missing links in the README.md

Since the signup form is now taking phone number and email address, we should not send them as response for every API. No user should be able to see other user's phone number and email address.

No route other than GET users/self should return phone and email and that too only if query private is set to true

• Should have a Skills collection which will have 4 fields
  • Name
  • Awarded on
  • Awarded by
  • Why it was awarded
• Each user object will have a Skills property, which will be an array and contain the skills document id

create API contract for /tasks/:id/details

Details :- Real-Dev-Squad/website-members#293

Create GET POST PATCH... APIs for auction page.

Return recruiters collection data

Task

• Real-Dev-Squad/website-my#465

Proposed Solution (Flow-Chart)

• Real-Dev-Squad/website-my#465 (comment)

Before Change

GET /users/isUsernameAvailable/:username

Returns the availability of username.

• Params
  Required: username=[string]
• Body
  None
• Headers
  Content-Type: application/json
• Cookie
  rds-session: <JWT>
• Success Response:
  • Code: 200
    • Content: { 'isUsernameAvailable': <boolean> }
• Error Response:
  • Code: 401
    • Content:
      { 'statusCode': 401, 'error': 'Unauthorized', 'message': 'Unauthenticated User' }
  • Code: 500
    • Content:
      { 'statusCode': 500, 'error': 'Internal Server Error', 'message': 'An internal server error occurred' }

After Change

GET /users/isUsernameAvailable

Returns the availability of username.

• Params
  None
• Query
  Required: firstname=[string] (The first name of the user)
  Required: lastname=[string] (The last name of the user)
  Optional: dev=[boolean] (dev is passed to get username in the developer mode with the feature that are flagged)
• Body
  None
• Headers
  Content-Type: application/json
• Cookie
  rds-session: <JWT>
• Success Response:
  • Code: 200
    • Content: { 'username': <string> }
• Error Response:
  • Code: 401
    • Content:
      { 'statusCode': 401, 'error': 'Unauthorized', 'message': 'Unauthenticated User' }
  • Code: 500
    • Content:
      { 'statusCode': 500, 'error': 'Internal Server Error', 'message': 'An internal server error occurred' }

Title: Create API Contract for /request Route

Issue Description

Develop and document the API contract for the unified /request endpoint. The API contract should clearly define the request and response structures, including all required and optional fields for task creation requests.

Expected Behavior

A documented and approved API contract that includes all necessary fields and validation rules for the /request endpoint.

Current Behavior

No existing API contract for the /request endpoint.

Screenshots

N/A

Reproducibility

• This issue is reproducible
• This issue is not reproducible

Steps to Reproduce

N/A

Severity/Priority

• Critical
• High
• Medium
• Low

Additional Information

Ensure the API contract is reviewed with the team for feedback and approval.

Checklist

• I have read and followed the project's code of conduct.
• I have searched for similar issues before creating this one.
• I have provided all the necessary information to understand and reproduce the issue.
• I am willing to contribute to the resolution of this issue.

What to do?

• Create a APi contract for discord bot which adds the data whenever a /link or /verify command is being run.
• The request to the backend from Cloudflare worker (Discord Bot) has to be verified by a JWT token
• If the token is expired, the request is invalid
• If the payload is incorrect then also the request is invalid

AC

• Create an API contract for /users/idle and /users/idle?members=true

Link with

Issue #635

• It is a collection of Tasks
• Containing the following data

{
  title: String,
  description: String,
  status: Enum,
  tasks: [
    <TaskId>
    <TaskId>
  ],
  featureOwner: <UserId>,
  backendEngineer: <UserId>, 
  frontendEngineer: <UserId>,
  StartedOn: Epoch,
  EndsOn: Epoch, // Due date 
}

Parent Story

Real-Dev-Squad/todo-action-items#140

Can we take a look here please: https://github.com/Real-Dev-Squad/website-api-contracts/pull/40/files#r593776779

Contract to return all users who are members of RDS who are not assigned tasks

members page data is outdated

Add unAssigned status in task object
Discord discussion
Task object to be changed

There are no error responses in Challenges API contracts, please add the same.

Error responses can be collected from the code.

Define new member API contract to implement the feature request.

Required Changes

• Add migration route and github_user_id field

/migrations/addDefaultColorProperty this API adds a colors field to all existing users, who do not have a colors property

The API contract needs to be changed to

{
   "id": "String",
  "userId": "String",
  "first_name": "String",
  "Last_name": "String",
  "picture": {
            "publicId": "String",
            "url": "String"
        },
  "status": {
          "until":"TimeStamp",
          "updatedAt": "TimeStamp",
          "state": "String",
          "message": "String",
          "from": "TimeStamp"
       },
  "monthlyHours": {
        "committed": "Integer",
        "updatedAt": "TimeStamp"
      }
  }

What needs to be done?

• Create API contract for /cache
• Create API contract for /logs/:type

The route /users/userId/:userId is missing in the API Contracts of /users. Need to update it

If we make each API as a main folder under the repo, it would be difficult to navigate and understand the hierarchy.
For example, we would now have an auction page and investment page under crypto-site, so
crypto-site

crypto-site
|---- README.md
|---- auction
|      |---- README.md
|---- investment
       |---- README.md

instead of

.
|---- README.md
|---- auction
|      |---- README.md
|---- investment
       |---- README.md

Description:
Create comprehensive API Contracts for the /requests API to ensure clarity and consistency in request and response structures.

Details:

• API Endpoint: /requests
• Methods: POST, UPDATE, GET
• Feature Flag: dev (for development environment)

Requirements:

1. Define the request payload structure for the POST and UPDATE methods.
2. Specify the response structure for each method, including success and error scenarios.
3. Include data types, required fields, and possible values where applicable.
4. Ensure the schema adheres to established API design standards.

Purpose:
Facilitate clear communication between frontend and backend teams, ensuring a smooth integration process.