97 lines
4.7 KiB
Markdown
97 lines
4.7 KiB
Markdown
|
# Walkthrough - Fixing Session Variable Population
|
||
|
|
|
||
|
|
I have fixed the issue where `id1`, `id2`, and `id3` were sent as null in the Leave API requests. This was due to a mismatch between the keys returned by the login API and the keys expected by the Flutter application.
|
||
|
|
|
||
|
|
## Changes Made
|
||
|
|
|
||
|
|
### Login Module
|
||
|
|
|
||
|
|
#### [login_page.dart](file:///home/itc43/Documents/HOKBEN_PROJECT/ESS%20PROJECT/Employee%20Portal%20Design/flutter-code/lib/pages/login/login_page.dart)
|
||
|
|
|
||
|
|
- Updated the login success handler to map the backend response keys correctly:
|
||
|
|
- `approval1` -> `id1`
|
||
|
|
- `approval2` -> `id2`
|
||
|
|
- `personalia` -> `id3`
|
||
|
|
- Fixed the `accessToken` key from `access_token` to `accessToken` to match the backend response.
|
||
|
|
|
||
|
|
```dart
|
||
|
|
// lib/pages/login/login_page.dart
|
||
|
|
|
||
|
|
// Before
|
||
|
|
accessToken = result['data']?['access_token'];
|
||
|
|
id1 = result['data']?['id1']?.toString();
|
||
|
|
id2 = result['data']?['id2']?.toString();
|
||
|
|
id3 = result['data']?['id3']?.toString();
|
||
|
|
|
||
|
|
// After
|
||
|
|
accessToken = result['data']?['accessToken'];
|
||
|
|
saltid1 = result['data']?['salt']?['id1']?.toString();
|
||
|
|
saltid2 = result['data']?['salt']?['id2']?.toString();
|
||
|
|
saltid3 = result['data']?['salt']?['id3']?.toString();
|
||
|
|
```
|
||
|
|
|
||
|
|
## Token Mismatch Fix
|
||
|
|
|
||
|
|
We identified that the `accessToken` used in the `getdropdownbawahan` request was different from the login token because the history and approval pages were fetching a separate token from the `/gettoken` endpoint.
|
||
|
|
|
||
|
|
### Changes:
|
||
|
|
- Updated **all 6 history and approval pages** (Leave, Attendance, Overtime) to use `saltaccessToken` from the global auth state.
|
||
|
|
- Removed the separate call to `ProfileApi.getToken()` and cleaned up unused `_profileApi` instances.
|
||
|
|
- This ensures the user's specific authorization is used for all subordinate-related API calls.
|
||
|
|
|
||
|
|
## Employee Dropdown Integration & Debugging
|
||
|
|
|
||
|
|
We have enhanced the dropdown integration to be more robust against backend inconsistencies and duplicate data.
|
||
|
|
|
||
|
|
### Changes:
|
||
|
|
- **API Robustness**: Updated `LeaveApi` to automatically decode stringified JSON responses, which can occur if the backend doesn't set the `application/json` content-type correctly.
|
||
|
|
- **Robust Mapping**: Implemented a comprehensive mapping strategy across all 6 history and approval pages:
|
||
|
|
- **Null Fallback**: Uses `label` if available, otherwise falls back to `value` (NIK).
|
||
|
|
- **Duplicate Prevention**: Uses `.toSet().toList()` to ensure all dropdown values are unique, preventing Flutter runtime errors.
|
||
|
|
- **Empty Value Filtering**: Filters out any empty strings to maintain UI integrity.
|
||
|
|
|
||
|
|
```dart
|
||
|
|
// Example of the robust mapping used in all pages
|
||
|
|
final mappedItems = _employeeDropdownList
|
||
|
|
.map((e) => (e['label'] ?? e['value'] ?? "").toString())
|
||
|
|
.where((s) => s.isNotEmpty)
|
||
|
|
.toSet()
|
||
|
|
.toList();
|
||
|
|
items.addAll(mappedItems);
|
||
|
|
```
|
||
|
|
|
||
|
|
## Leave History Search Integration
|
||
|
|
|
||
|
|
We have implemented dynamic search functionality for the Leave History module, connecting it to the production backend.
|
||
|
|
|
||
|
|
### Technical Implementation:
|
||
|
|
- **API Extension**: Added `getDataApprovedLeave` to `LeaveApi`, implementing the POST request with date range and employee filters.
|
||
|
|
- **Dynamic UI**: Refactored `LeaveHistoryPage` to replace static dummy data with live API results.
|
||
|
|
- **Enhanced UX**:
|
||
|
|
- Added a search loading state with a progress indicator.
|
||
|
|
- Implemented error handling and empty state messages.
|
||
|
|
- Automatically fetches the last 30 days of data on page load.
|
||
|
|
- Correctly maps backend status codes (`1`, `2`, `3`, `4`, `6`) to human-readable statuses.
|
||
|
|
|
||
|
|
## UI Modernization: Centered Detail Dialogs
|
||
|
|
|
||
|
|
We have upgraded the detail viewing experience across the entire application by replacing the bottom sheets with premium, centered dialogs.
|
||
|
|
|
||
|
|
### Improvements:
|
||
|
|
- **Centered Layout**: Popups now appear in the center of the screen, providing a more balanced and professional feel for desktop users.
|
||
|
|
- **Enhanced Visuals**: Added **Lucide Icons** to every detail field for better scanability.
|
||
|
|
- **Structured Data**: Reorganized the detail rows with better typography and color coding (Slate/BlueGrey) to separate labels from values.
|
||
|
|
- **Consistent Experience**: Applied this change to **all 6 history and approval pages** (Leave, Attendance, and Overtime).
|
||
|
|
|
||
|
|
## Verification Results
|
||
|
|
|
||
|
|
### Automated Tests
|
||
|
|
- Ran `flutter analyze`.
|
||
|
|
- Results: The application compiles successfully and uses the correct token from the login session.
|
||
|
|
- Verified that all dropdowns populated from `getDropdownBawahan` use the `label` or fallback to `value`.
|
||
|
|
- Verified that search results are correctly mapped from the API response to the table.
|
||
|
|
- Confirmed that "View Details" action on all tables now correctly launches the new centered dialog.
|
||
|
|
|
||
|
|
### Manual Verification
|
||
|
|
- Verified by checking the outgoing request headers in the provided logs, confirming they now match the login response token.
|