danielgilchrist / tanda_cli Goto Github PK

This enables features like displaying how much longer you have in the day based on your worked shifts/breaks

Currently there's weird spacing for some of the commands that make use of Representers::SomeModel and this is mostly because they output a "\n" after outputting their contents. We should give control to the caller to determine when this is necessary

Add a command to view your current roster or your roster on a particular date

https://my.tanda.co/api/v2/documentation#rosters

Clock in validations work great if the only changes to a shift and its breaks are made through clock ins (timeclock, gps clock in, clockin command) but end up incorrectly throwing validation errors or letting invalid clock ins go through if it's edited directly. The logic should probably be determining the state based on the shift and its breaks instead

Currently if a request is made and fails due to an expired or invalid token the user has to manually run the command to fetch a new token. It'd be nice if the program asked the user if they want to refetch the token for convenience

Using an existing webcam device would be too difficult and potentially invasive so it would be nice to be able to specify a specific image or directory to sample from for clock in photos

When taking a break the time during the break is still displayed as time worked until the break finishes for the time_worked command

Example: Second break taken at 5:07pm and it is now 8:01pm

Adding --photo every time for the clockin command is annoying. It'd be nice to be able to configure a specific photo or a directory of photos (where a random photo would be picked each time) to make clocking in with a photo easier

Currently when you clock in if there's a timeclock question the question isn't asked and therefore you can't answer it. After clocking in we should fetch timeclock questions and allow the user to answer.

This should be configurable

https://my.tanda.co/api/v2/documentation#timeclock-questions

If you forget to clockin you have to manually update the shift. It'd be nice to have a command to add the time you should have clocked in to the shift

In this case a validation error occurs and blocks the command to clock out unless overridden with --skip-validations e.g.

tanda_cli clockin finish --skip-validations

This currently only applies to the time_worked week command but currently Monday is the default week start day. It'd be nice if this was configurable

Clockins are already validated by default when using tanda_cli clockin start, tanda_cli clockin finish, etc so that you don't accidentally clock in when you meant to clock out and vice versa. When the validation error appears you're usually just going to follow its suggestion and use the correct command so what if we didn't have to specify the type at all? A command like tanda_cli clockin auto or something could be nice

Likely due to nesting OptionParser.parse inside the top level one
e.g.

Poor design decisions in the repo makes it hard to write tests

1. Current singleton is a nightmare to test
2. A lot of commands make API calls (possibly https://github.com/manastech/webmock.cr)
3. Lots of places exit to return early which makes testing hard
4. Getting output and asserting on it is hard (see exit in point above)
5. Probably more

Likely want to see how https://github.com/crystal-lang/shards does testing

Add a command for viewing personal details for the selected current_user

https://my.tanda.co/api/v2/documentation#personal-details

After #132 a user can select the scopes they want tanda_cli to have access to when requesting a token.

Currently it shows this error message if you use a command

I think it'd be nicer if commands that require scopes that weren't authorised aren't registered at all and therefore don't show in the help menu and can't be called from the CLI

https://my.tanda.co/api/v2/documentation#shift-ratings

A command that gives you an overview of your leave taken, future leave and how much leave you have left

Nightly is a lot more likely to fail from existing code / shards than changes in a PR so it doesn't really make sense to block the PR if the check fails. I think it makes sense to only run nightly on main and fix any issues in another branch rather than in the branch it fails on

Uncommon but when there are multiple shifts on a day the command becomes harder to understand without explicitly looking at the date for each shift