1. User Authentication and Role-Based Access

• Description: The foundational step involved setting up a basic user authentication system. Upon successful login, a user's role (either 'maker' or 'checker') is determined and stored locally. This role then dictates the visibility and functionality of various UI elements throughout the application.
• Logic:
  • localStorage.setItem('role', userRole): Stores the assigned role in the browser's local storage.
  • localStorage.getItem('role'): Retrieves the role when the HomeComponent initializes.
  • role: string | null = null;: A component property holds the retrieved role.
  • ngIf="role === 'maker'" or *ngIf="role === 'checker'": Angular's structural directive used in the HTML template to conditionally render buttons, forms, or entire sections based on the user's role.
• Key Libraries/Functions: localStorage (Web API), Angular's *ngIf directive.

2. Initial Transaction Table Display (Pre-AG Grid)

• Description: Before integrating AG-Grid, a basic HTML <table> was likely used to display transaction data fetched from the backend. This provided a foundational view of the transactions.
• Logic:
  • loadTransactions(): An asynchronous method that performs an HTTP GET request to your backend API (http://localhost:3000/api/transactions).
  • transactionList: Transaction[] = [];: A component array to store the raw transaction data received from the API.
  • ngFor="let txn of transactionList": Used in the HTML to iterate over the transactionList and render each transaction as a row in the table.
• Key Libraries/Functions: @angular/common/http (HttpClient), rxjs operators (tap, catchError, of), Angular's *ngFor directive.

3. Transaction Creation (Modal Form)

• Description: To allow 'maker' users to add new transactions, a modal form was implemented. This form collects details like 'From Account', 'To Account', 'Amount', 'Currency', and 'Description'.
• Logic:
  • showAddForm: boolean: Controls the visibility of the modal form.
  • toggleAddForm(): Toggles the showAddForm boolean.
  • addTransaction(form: NgForm): Triggered on form submission. It constructs a new Transaction object (initially with a temporary client-side ID and 'PENDING' status).
  • Optimistic UI Update: The new transaction is immediately added to the local transactionList (unshift) and the grid is updated, providing instant feedback to the user.
  • HttpClient.post<Transaction>(this.apiUrl, newTxnData): Sends the new transaction to the backend. Upon successful response, the local transaction is updated with any server-generated IDs or timestamps. Error handling reverts the UI change if the backend call fails.
• Key Libraries/Functions: @angular/forms (NgForm), HttpClient.post, Array.prototype.unshift(), updateGridDataAndFilters().

4. Transaction Editing (Modal Form)

• Description: Building on the form concept, 'maker' users were given the ability to modify existing transactions. An "Edit" button for each transaction would open a pre-filled modal form.
• Logic:
  • showEditForm: boolean: Controls the visibility of the edit modal.
  • editingTransaction: Transaction | null: Stores a copy of the transaction being edited.
  • onEditClick(transaction: Transaction): Sets editingTransaction and showEditForm = true.
  • updateTransaction(form: NgForm): Triggered on edit form submission. It sends a PATCH/PUT request to the backend with the updated data.
  • Optimistic UI Update: Similar to creation, the local transactionList is updated immediately. If the backend update fails, the original transaction data is restored, and the grid is reloaded for consistency.
• Key Libraries/Functions: HttpClient.put, Array.prototype.findIndex(), updateGridDataAndFilters().

5. Transaction Status Management (Accept/Reject/Delete)

• Description: This feature introduced the core workflow for 'checker' users to review and change transaction statuses. It includes accepting, rejecting (with a mandatory reason), and deleting transactions. Confirmation modals were added to prevent accidental actions.
• Logic:
  • confirmAction(actionType, transactionId): A generic method that sets a modalMessage and a modalAction (a callback function) for a confirmation modal. This is used for 'accept' and 'delete' actions.
  • promptForRejectionReason(transactionId): A specific method to open a modal that prompts the 'checker' for a rejectionReasonInput before proceeding with rejection.
  • updateTransactionStatus(id, newStatus, rejectionReason, byUser): The central method that sends an HTTP PATCH request to the backend to change a transaction's status and update related fields (acceptedAt, rejectedBy, rejectionReason).
  • The local transactionList is updated optimistically, and a full loadTransactions() is performed on error to ensure data integrity.
• Key Libraries/Functions: HttpClient.patch, custom modal state variables (showConfirmModal, showReasonModal), Date.prototype.toISOString().