4.7 KiB
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
- Updated the login success handler to map the backend response keys correctly:
approval1->id1approval2->id2personalia->id3
- Fixed the
accessTokenkey fromaccess_tokentoaccessTokento match the backend response.
// 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
saltaccessTokenfrom the global auth state. - Removed the separate call to
ProfileApi.getToken()and cleaned up unused_profileApiinstances. - 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
LeaveApito automatically decode stringified JSON responses, which can occur if the backend doesn't set theapplication/jsoncontent-type correctly. - Robust Mapping: Implemented a comprehensive mapping strategy across all 6 history and approval pages:
- Null Fallback: Uses
labelif available, otherwise falls back tovalue(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.
- Null Fallback: Uses
// 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
getDataApprovedLeavetoLeaveApi, implementing the POST request with date range and employee filters. - Dynamic UI: Refactored
LeaveHistoryPageto 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
getDropdownBawahanuse thelabelor fallback tovalue. - 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.