nijuyonkadesu / celestidesk

streamlines permission request / grant mechanism and, notifies employees whether their request has been approved or not through mail / sms

Hi there👋 It's me

24k🍂 #𝓑𝓾𝓲𝓵𝓽_𝓭𝓲𝓯𝓯𝓮𝓻𝓮𝓷𝓽

• 🌱 Good at Kotlin | Android App Development
• 🚀 Trying out Jetpack Compose | Kotlin Multiplatform Mobile
• ⏱️ Plans to explore ML | AI

Languages and Tools:

 

Contact me :

celestidesk's Issues

feat(nav bar): chips are making the ui more complex to understand

Is your feature request related to a problem? Please describe.
From the user's perspective, there is lot of text and almost 0 visual communication about what kind of infomation the user is seeing. Unless they understand meaning of Processing, Reviewing means. This needs simplification.

Describe the solution you'd like

1. Bring a bottom navigation bar, which displays [Requests] that contains, all requests of all stages, without filtering.
2. Later, when [Transactions] is implemented, it can be also shown in bottom bar.
3. Add some colors to each item to let users know that:

'This is not a regular request, but it is waiting for to get approved by another person.Wwe need to take actions on items with this color'

This way, user interaction is minimized, and is made easy to understand.

feat(release): configure for release build

Is your feature request related to a problem? Please describe.
Release build requires removing all logging statements. Without log statement, how do I debug on app crashes ?

Describe the solution you'd like

• Wrap all Log statements with if, so it won't appear in release build.
• Make promotional materials needed for playstore release
• Add Proguard configuration
• Test minify build

Describe alternatives you've considered
Something like crashlytics is needed in absence of Log statements.

Additional context
https://github.com/davquar/halfdot - but this is not crashlytics tho

feat(request): show more details on the request card

Is your feature request related to a problem? Please describe.
Very minimal information is shown on each Request Card. Current implementation represents:

Pic Placeholder | Subject | Date
THE MESSAGE

Describe the solution you'd like
These additional fields can be shown on each Request Card.
[ + is addition, - is removal ]

+ Validity icon (ORANGE / GREEN) // Visual communication on whether the request got expired or not
- Date
+ Name
+ From [DATE]
+ To [DATE]
+ Progress bar // visually tell how many days have been passed since the *FROM* date

Additional context
Remember! Requests can be made in advanced. which means, you may end up with negatives values when using 'From' and 'To' date values. Maybe consider adding another visual element to tell 'this request' is made in advance ?

feat(icon): need a new app icon

Is your feature request related to a problem? Please describe.
No. Need a app icon. Can be used as splash icon too.

Additional context

• See bodymoving plugin in after effects for splash screen animation
• follow icon design principles

feat(search): full text searching on entire transaction list

Is your feature request related to a problem? Please describe.
There's no way to properly navigate through transaction page. It will be better to do a seach on any field and find past actions. It's an useful way for MANAGER to quickly find people

Describe the solution you'd like
SearchBar:

• Material Search Bar
• Search view with flow - Integrate with above

Quick Sample:

searchView.getQueryTextChangeStateFlow()
    .debounce(300)
    .filter { query ->
        if (query.isEmpty()) {
            textViewResult.text = ""
            return@filter false
        } else {
            return@filter true
        }
    }
    .distinctUntilChanged()
    .flatMapLatest { query ->
        dataFromNetwork(query)
            .catch {
                emitAll(flowOf(""))
            }
    }
    .flowOn(Dispatchers.Default)
    .collect { result ->
        textViewResult.text = result
    }

FTS4:

1. Set Content Entity (Transaction class)
2. Create Entity: TransactionFts (with what fields we shd consider for finding search results)
3. • do: @fts4(contentEntity)
   • don't: Map Transaction -> TransactionFts guide
4. Include Fts entity to room: Return Flow<List<>>
5. Search!! @Query("SELECT * FROM note_fts WHERE note_fts MATCH :searchText") smth like this

Additional context
Make sure to append instead of replacing transaction list in room database.

fix(inaccuracy): it's time to mass squash all lurking bugs

Describe the bug

1. The progress bar itself in main screen request card
2. Check data class consitency once again
3. Missing error handling on input text fields
4. Permitting blank requests to server
5. Block UI when waiting for server response
6. Add swipe to refresh layout in main screen
7. First Screen of the app
8. Try using saved statehandle if necessary (to prevent crashes)
9. The initial error message on login screen
10. Nuke entire database on logout [Check if it works again]
11. Update all dependencies [toml file]
12. Try refactoring / rearranging source
13. Allow calendar to only select future dates
14. Logout icon crash

To Reproduce

Steps to reproduce the behavior:

1. Try every feature of app in misc conditions, these are obvious to a long time user
2. Rotate screen while bottom bar is open, or any form for that matter

Additional context

(。_。)

fix(hardcode): replace all hardcoded values with string resource

Describe the bug

The analogy of EMPLOYEE, TEAM_LEAD, MANAGER is adopted for better understanding of the application code. The actual usecase may vary. For example, if college wants to adapt this for their purpose, they might have different role names. Having them in a separate string file will reduce the refactoring costs, and reduces human error.

Expected behavior

Retrieve string resources from xml file. Maybe also attach a locale value to it.

Actual behavior

It's all hardcoded string in celestidesk

Additional context

Localization guide
force a locale

feat(strikethrough): visually show a invalid request

Is your feature request related to a problem? Please describe.
Speaking from employee's point of view, if you arrive late, the app should communicate it visually.

Describe the solution you'd like
All of your requests will be crossed with red line. Seeing one is obvious that this person is late ~

Describe alternatives you've considered
Maybe... You can have [Valid] and [Invalid] sections in Approved chip. So that it'll be more easy to separate new & old requests visually.

Additional context

• conditionally add drawable strike_through.xml
• group by in ROOM db

feat(role): add a role that can handle emergency requests

Describe the solution you'd like
A new role, that should handle emergency requests raised by employees