Client Management System

Author(s)

• Arpita Dey

Last Updated Date

2024-10-01

---

SRS References

• 2.1.2

---

Version History

Version	Date	Changes	Author
1.0	2024-10-01	Initial draft	Arpita Dey
...	...	...	...

---

Feature Overview

Objective:
A customer can have multiple clients, with each client handling one or more cases. Within these cases, there can be several synchronized jobs. The Client Management screen is designed to allow different user roles to view and manage clients, cases, and synchronized jobs based on their permissions.

Scope:

This feature is designed to effectively manage all client and case-related activities. The following scopes provide flexible access for management:

client.view : This scopes is intended to grant access to the client management system, enabling users to view all clients, their associated cases, and the corresponding jobs

client.create : This scope allows users to add new clients and create cases under any existing client.

client.update : This scope allows users to update clients and cases.

client.delete : This scope allows users to delete clients and cases.

Currently, this feature does not support to switch synchronized jobs between cases or move cases from one client to another.

Dependencies:
No.

---

Requirements

1. SuperAdmin Rights: The SuperAdmin has full access to all clients, cases, and synchronized jobs. They can create new clients, add cases under any client, and have the ability to edit or delete any client or case in the system.
2. Admin Rights : An Admin can only view the clients, cases, and jobs they have claimed. While they have the ability to edit or delete the displayed clients and cases, they cannot add new clients or cases.
3. StandaloneUser Rights: A Standalone User can view their own clients, cases, and synchronized jobs. They have the ability to create new clients and cases, as well as edit or delete their own clients and cases.
4. Users having permissions can delete clients; however, they are only able to delete clients that do not have any associated cases.
5. Users having permissions can delete cases; however, they are only able to delete cases that do not have any sync jobs.

---

Design Specifications

API : Add new client

• UI/UX Design:
  (Include wireframes, mockups, or links to design files.)

• Data Models:
  The following is the breakdown of the ClientStruct class

  public class ClientStruct : ClientMaster
    {
        [Column(TypeName = "jsonb")]
        public List<CaseStruct>? Cases { get; set; } = null;
    }

API : Update client

• UI/UX Design:
  (Include wireframes, mockups, or links to design files.)

• Data Models:
  The following is the breakdown of the ClientStruct class

  public class ClientStruct : ClientMaster
    {
        [Column(TypeName = "jsonb")]
        public List<CaseStruct>? Cases { get; set; } = null;
  
    }

API : Get all clients

• UI/UX Design:
  (Include wireframes, mockups, or links to design files.)

• Data Models:
  The following is the breakdown of the ClientMaster class

     public class ClientMaster
    {
        public Guid ClientId { get; set; }
        public string? ClientName { get; set; }
        public Guid? SubscriptionId { get; set; }   
        public Guid? UserId { get; set; }           
        public bool IsActive { get; set; } = true;
        public ClientMetaData? ClientMetaData { get; set; } = null;
        public ClientCompanyDetails? ClientCompanyDetails { get; set; } = null;
        public string? CreatedBy { get; set; }
        public DateTime? CreatedOn { get; set; }
    }

API : Add new case

• UI/UX Design:
  (Include wireframes, mockups, or links to design files.)

• Data Models:
  The following is the breakdown of the CaseStruct class

    public class CaseStruct
    {
        public Guid CaseId { get; set; }
        public string? CaseName { get; set; }
        public string Description { get; set; } = string.Empty;
    }
    public class CaseCreateStruct
    {
        public Guid ClientId { get; set; }
        public CaseStruct? CaseDetails { get; set; }
    }
  
    public class SyncJobFilterStruct
    {
        public SyncJobQueryType QueryType { get; set; } = SyncJobQueryType.NoFilter;
        public Guid? Id { get; set; } = null;
        public string? DisplayCode { get; set; } = null;
        public Guid? CaseId { get; set; } = null;
        public JobState State { get; set; } = JobState.Unset;
        public DateTime? StartDate { get; set; } = null;
        public DateTime? EndDate { get; set; } = null;
        public string? UserId { get; set; } = null;
        public int PageNumber { get; set; } = 0;
        public int RowsPerPage { get; set; } = 0;
    }
    public enum SyncJobQueryType
    {
        NoFilter,
        JobId,      // auto generated Guid
        JobCode,    // auto generated publicly shared id
        Multi,
        CaseId
    }
    public class SyncJobStruct
    {
    [Key]
    public required Guid SyncId { get; set; } = Guid.NewGuid();//ContainerId
    public required string TransId { get; set; }
    public string DisplayId { get; set; } = string.Empty;
    public string Description { get; set; } = string.Empty;
    public DateTime UploadDateTime { get; set; }
    public DateTime ExpectedDateTimeOfCompletion { get; set; }
    public string? OrganizationId { get; set; } = null;
    public string? CreatedByUserId { get; set; } = null;
    public string? AssignedToUserId { get; set; } = null;
    public SyncJobState SyncJobState { get; set; }
    public JobProcessMode ProcessMode { get; set; } = JobProcessMode.Unset;
    public DateTime SyncJobStartDate { get; set; }
    public DateTime SyncJobEndDate { get; set; }
    [NotMapped]
    public DepositionStruct? DepositionData
    {
        get
        {
            return JsonConvert.DeserializeObject<DepositionStruct>(this.DepositionObject);
        }
  
        set
        {
            this.DepositionObject = JsonConvert.SerializeObject(value);
        }
    }
    [JsonIgnore]
    public string DepositionObject { get; set; } = string.Empty;
    [ForeignKey("SyncJobFinances")]
    public Guid? FinanceId { get; set; } = Guid.Empty;
    public void Update(SyncJobStruct copyFrom)
    {
        TransId = copyFrom.TransId;
        SyncId = copyFrom.SyncId;
        DisplayId = copyFrom.DisplayId;
        Description = copyFrom.Description;
        UploadDateTime = copyFrom.UploadDateTime;
        ExpectedDateTimeOfCompletion = copyFrom.ExpectedDateTimeOfCompletion;
        AssignedToUserId = copyFrom.AssignedToUserId;
        SyncJobState = copyFrom.SyncJobState;
        DepositionData = copyFrom.DepositionData;
        FinanceId = copyFrom.FinanceId;
        SyncJobStartDate = copyFrom.SyncJobStartDate;
        SyncJobEndDate = copyFrom.SyncJobEndDate;
    }
  
  }
  

• API Interfaces:

  Endpoint	Method	Parameters	Response	Response Status Codes
  /client/create	POST	ClientStruct(required)	ClientId(Guid)	200, 204,400, 500
  /client/view?clientName={clientName}&primaryEmail={primaryEmail}	GET	ClientName (optional, string?),PrimaryEmail (optional, string?),PageNumber (required, int) : default value 1,RowsPerPage (required, int) : default value 10	List Of ClientMaster / Empty array for no data	200, 204, 500
  /client/update	PUT	ClientStruct(required)	String (Message)	200,201, 204, 500
  /client/delete?clientId={clientId}	DELETE	ClientId	String (Message)	200, 204, 500
  /case/create	POST	CaseCreateStruct	String (Message)	200, 204, 500
  /case/view?clientId={clientId}	GET	ClientId(Guid)	List Of CaseStruct	200, 204, 500
  /case/delete?caseId={caseId}	DELETE	caseId(Guid)	String (Message)	200, 204, 500
  /case/update?caseId={caseId}&description={description}	PATCH	CaseCreateStruct	String (Message)	200, 204, 500
  /syncjob/list	POST	SyncJobFilterStruct	List Of SyncJobStruct	200, 204, 500

• Third-Party Integrations:
  (List any third-party services or tools that need to be integrated.)

Workflow:

1. User Authentication and Role Assignment:

   • The system authenticates users and determines their role (SuperAdmin, Admin, StandaloneUser).
   • Based on their role, the user receives the appropriate permissions to access the Client Management system.

2. Client Management:

   • SuperAdmin:
     • Can access all clients, create new clients, and view, edit, or delete any client or case in the system.
     • If a client is deleted, the system checks for associated cases. If no cases are present, the client is deleted. If there are cases, the deletion is denied.
   • Admin:
     • Admins can only view, edit, or delete clients they have claimed.
     • They cannot create new clients or cases, but they can manage those they have been assigned.
   • StandaloneUser:
     • Standalone users can only view their own clients and cases. They have the ability to create new clients and cases, or edit/delete their own clients and cases.

3. Case Management:

   • Users create new cases under a specific client by providing necessary details (e.g., case name, description).
   • The system checks that the user has permission to manage the client and then associates the new case with that client.
   • Cases can only be deleted if they do not have any synchronized jobs.

4. Job Synchronization:

   • Jobs are automatically synced under cases, but they cannot be moved between cases or clients at this stage.

5. API Call Process:

   • Users trigger specific API endpoints based on their actions:
     • POST /client/create: Creates a new client.
     • GET /client/view: Retrieves all client details for the user.
     • PUT /client/update: Updates existing client details.
     • DELETE /client/delete: Deletes clients that have no associated cases.
     • POST /case/create: Creates a new case under a specific client.
     • GET /case/view: Retrieves case details for the user.
     • DELETE /case/delete: Deletes cases that have no synchronized jobs.

6. Error Handling and Notifications:

   • The system checks for any errors or violations in role permissions before processing API requests.
   • Users are notified of successful operations or errors (e.g., trying to delete a client with associated cases or cases with synchronized jobs).

7. Data Persistence:

   • All actions (create, update, delete) are committed to the database after validation.
   • Any change is reflected in real-time and updated for all users with the necessary permissions.

8. Logging and Auditing:

   • The system logs all actions, including who created, edited, or deleted clients/cases for audit purposes.
   • These logs can be reviewed by SuperAdmin users if needed.

9. System Testing and Feedback Loop:

   • After each significant update or interaction, integration and unit tests ensure the functionality works as expected.
   • QA teams provide feedback on the user experience and functionality before production rollout.

---

Development Tasks & Estimates

(Break down the development process into smaller tasks and provide time estimates for each.)

No	Task Name	Estimate (Hours)	Dependencies	Notes
1	Client Management	4hr
2	Case Management	3hr
3	Job Listing	45min
4	Integration Testing	1 hours
5	Front-end - Client Managment	4 hours
6	Front-end - Case Managment	2 hours
7	Front-end - Jobs Managment	1.5 hours
8	Front-end - Customer Management	4 hours
9	Total	19 hours 15min

---

Testing & Quality Assurance

• Unit Tests:

  • Each API should have comprehensive unit tests to validate the functionality of individual components.
  • Example tests:
    • Test POST /client/create to verify client creation with valid data.
    • Test GET /client/view?clientName={clientName}&primaryEmail={primaryEmail} to ensure the client details are returned correctly.
    • Test PUT /client/update to check if the client information is updated.
    • Test DELETE /client/delete?clientId={clientId} to verify client deletion only for clients with no associated cases.
    • Test POST /case/create to ensure case creation under a specific client.
    • Test GET /case/view?caseId={caseId} to validate the correct retrieval of case details.
    • Test DELETE /case/delete?caseId={caseId} to verify cases can only be deleted when no synchronized jobs are present.

• Integration Tests:

  • Conduct integration tests to ensure that all APIs interact correctly with each other.
  • Example scenarios:
    • Test POST /client/create followed by GET /client/view?clientName={clientName} to validate data persistence.
    • Test POST /case/create and check that the case appears in subsequent GET /client/view?clientName={clientName} calls.
    • Ensure that deleting a client using DELETE /client/delete?clientId={clientId} cascades correctly, depending on associated cases and jobs.

• Acceptance Criteria:

  • The system must allow users with appropriate permissions to create, update, view, and delete clients and cases as defined in the roles and permissions.
  • Client and case deletion should follow the conditions for removing clients without associated cases and cases without synchronized jobs.
  • All APIs should return appropriate HTTP status codes and messages based on the operation's success or failure.
  • No system-level errors should occur during any API call execution.

• Testing Tools:

  • Postman or similar API testing tools for manual tests.
  • XUnit or NUnit for automated unit and integration tests within the .NET framework.
  • Mocking frameworks such as Moq to simulate dependencies like database operations.

---

Deployment Considerations

• Configuration Changes:

  • Ensure API endpoints are properly configured in the production environment with correct base URLs and authentication.
  • The system should be set up with role-based access control (RBAC) for different user roles (SuperAdmin, Admin, StandaloneUser).
  • Database migrations for new tables or fields (like ClientMetaData, ClientCompanyDetails, etc.) should be run smoothly.

• Rollout Plan:

  • Perform a phased rollout, starting with a small group of users for initial testing.
  • Gradually expand the release to the full user base after confirming stability and functionality.
  • Include feature toggles to enable or disable the new client and case management features without affecting existing functionality.

---

Risks & Mitigations

Risk	Impact	Likelihood	Mitigation Strategy
Data loss during deletion	High	Medium	Implement soft-delete functionality to archive clients/cases before final deletion
Unauthorized access	High	Medium	Enforce strict role-based access controls (RBAC) for all API endpoints
Inconsistent data states	Medium	Low	Use transactions to ensure atomic operations for creating/updating clients and cases
API performance issues	Medium	Medium	Optimize API queries and use pagination for data-heavy responses, such as viewing multiple clients/cases

---

Review & Approval

• Reviewer:
  Rupanjan Hari

• Approval Date:
  2024-10-05