Krow/Krow-workspace
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update NEXT_SPRINT_TASKS.md

Browse Source
This commit is contained in:
Achintha Isuru
2026-02-04 14:42:49 -05:00
parent 3e5ad2c51a
commit c8dcf739c6
1 changed files with 24 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
apps/mobile/NEXT_SPRINT_TASKS.md
View File

@@ -2,7 +2,6 @@
* In the mobile applications, since the structure is now finalized (at least for the existing features), we need to **strictly follow best practices while coding**: * In the mobile applications, since the structure is now finalized (at least for the existing features), we need to **strictly follow best practices while coding**:
* Break down large widgets into **smaller, reusable widgets** * Break down large widgets into **smaller, reusable widgets**
* Add **doc comments** where necessary to improve readability and maintainability * Add **doc comments** where necessary to improve readability and maintainability
* **Remove overly complicated or unnecessary logic** introduced by AI and simplify where possible * **Remove overly complicated or unnecessary logic** introduced by AI and simplify where possible
@@ -12,12 +11,34 @@
- apps/mobile/packages/features/client/client_coverage/lib/src/data/repositories_impl/coverage_repository_impl.dart - apps/mobile/packages/features/client/client_coverage/lib/src/data/repositories_impl/coverage_repository_impl.dart
- Fix the location field in CoverageShiftRole to use the correct fallback logic. - Fix the location field in CoverageShiftRole to use the correct fallback logic.
- line 125 remove redundant location values. - line 125 remove redundant location values.
- Need to clarify the difference b/w `case dc.ApplicationStatus.ACCEPTED` and `case dc.ApplicationStatus.CONFIRMED`. - Need to clarify the difference b/w `case dc.ApplicationStatus.ACCEPTED` and `case dc.ApplicationStatus.CONFIRMED`.
- Update the dataconnect docs. - Update the dataconnect docs.
- Track `lat` and `lng` in the staff preferred work locations (for now we are only storing the name). - Track `lat` and `lng` in the staff preferred work locations (for now we are only storing the name).
- Remove "Up Next (x)" counter from orders list in client app as it is confusing, becase the tab already has a badge showing the number of the upcoming orders.
- ` final String status;` in `OrderItem` make it an enum. - ` final String status;` in `OrderItem` make it an enum.
- /// Date of the shift (ISO format). - /// Date of the shift (ISO format).
final String date; make this in the DateTime format instead of string. final String date; make this in the DateTime format instead of string.
- in `view_orders_cubit.dart` combine the logic of `_calculateUpNextCount ` and `_calculateTodayCount` into a single function that calculates both counts together to avoid redundant filtering of orders. - in `view_orders_cubit.dart` combine the logic of `_calculateUpNextCount ` and `_calculateTodayCount` into a single function that calculates both counts together to avoid redundant filtering of orders.
- In places api call in the when the api's not working we need to show a proper error message instead of just an empty list. - In places api call in the when the api's not working we need to show a proper error message instead of just an empty list.
- pending should come first in the view order list.
- track minimum shift hours in the staff profile and show a warning if they try to apply for shifts that are below their minimum hours.
- this need to be added in the BE and also a FE validation (5 hrs).
- Cannot cancel before 24 hours of the shift start time. If do we should charge for 4 hours of work for each shifts.
- verify the order creation process in the client app.
- Vendor don't need to verify the order, when the order is created it should be automatically published.
- rethink the order status, we need to simplify it.
- Validation layer
- Profile info
- emergency contact
- experiences
- attires
- there should be manual verification by the client even if the ai verification is passed.
- to track false positives and false negatives.
- certifications
- there should be manual verification by the client even if the ai verification is passed.
- to track false positives and false negatives.
- documents
- tax forms