| Age | Commit message (Collapse) | Author |
|---|
|
I personally think this tool "vastly improves" upon the Chrome
extension. After all, it's much more flexible, and it lives in the
console, both of which are immense pluses.
|
|
Split the example code onto multiple lines to improve readability.
|
|
I thought it would be cool if we showed off an example connecting
`timetasker` with another shell command.
|
|
Makes it a bit easier to read as text.
|
|
Installation instructions.
|
|
Explain the program's configuration and how to configure it using data
from TimeTask.
|
|
Show some examples of how to use the program.
|
|
Remove references to the project being abandoned. Briefly describe it.
|
|
|
|
|
|
Take the errors in `main()` that check the response body contents for
known error strings and put them in their respective functions in
"timetask/http.go".
Didn't really make sense to me that these functions were returning HTTP
responses that we weren't really using in a meaningful way. Instead they
should just do their thing and let us know if there was a problem.
That includes checking to see if there were any non-standard errors,
like the ones we had custom-built. Now all that handling and
error-making is self-contained, which feels much nicer.
|
|
|
|
|
|
Parse the module XML with `ModuleParseXML()`. Take the resulting
`[]Module` slice and use it to generate a string of the following
format:
ID Module
55555 R&D
77777 Sprint 1
222222 Sprint 2
This string is what gets printed to the console, which makes it rather
easy to read the modules that are available for the given project and
grab the appropriate ID to put into your config file.
|
|
Prefix the function name to make it more obvious what it relates to.
Since this function lives in the `timetask` module and will be used in
contexts that have nothing to do with Modules.
|
|
A new function that parses the XML returned by the `RequestModules()`
function.
It provides a `Module` type that allows us to interact with modules more
easily in code.
The `ParseXML()` function will take an XML string and return a slice of
`Module`s.
Added a test just to facilitate development. Wasn't able to find an easy
way to compare slices in Go, so just printed the values and checked the
result visually. Not a useful test for future use, but it served its
purpose. Eventually it would be nice to find a way to compare structs
and have a real pass/fail condition.
|
|
`Login()` now returns 3 values. Update the test.
|
|
Sprints will change with time while the other IDs of a project will stay
the same. Thus sprints, which live in the `Module` field, must be
updated regularly.
In order to facilitate that updating, instead of requiring users to get
those IDs directly from the TimeTask website every time, have them use
this command to get the names of sprints and their IDs. They can then
update the ID manually in their config file.
This code makes a request to the endpoint that returns module IDs for
the site (the site queries this via AJAX to update its interface).
The result of the request is some XML containing the modules and their
IDs. For now I'm just printing this out. We'll want to parse the XML and
display it in a nicer way.
|
|
|
|
|
|
|
|
Add some simple error handling for known responses from our TimeTask
HTTP requests. Check a couple of known strings to determine whether
there was an error. If so, exit with a failing error code.
Remove our old `log` statements. These were used during debugging to see
some output and check responses from TimeTask. We now have an idea of
what those responses are, and are handling some of the error cases. Thus
the log statements are no longer needed.
|
|
|
|
Remove the initial cap on Kingpin error messages for consistency in our
messages.
|
|
|
|
|
|
Otherwise, if users haven't created a config file and they run `--help`,
they'll get an error complaining that the config file doesn't exist
instead of helpful usage output.
|
|
* Change the initial capital to lowercase for consistency with the other
error messages
* Suggest using `--write-config` as a possible solution to the error (in
cases where the config file doesn't exist)
|
|
Instead of loading the config file I've been testing with in the local
project directory, load the real one from XDG_CONFIG_HOME.
|
|
|
|
|
|
Given a string from `password_cmd`, we should execute it as a shell
command and assume the result is a password. That password then gets
submitted to TimeTask's login form for authentication.
Had to do a bit of wrangling to get the command to execute by
`exec.Command()`, but managed to get it working in a bit of a roundabout
way.
Found these resources in my searches:
- https://stackoverflow.com/questions/39930109/golang-execute-command#39930127
https://stackoverflow.com/questions/28783637/how-to-make-golang-execute-a-string
- https://stackoverflow.com/questions/20437336/how-to-execute-system-command-in-golang-with-unknown-arguments
- https://github.com/codeskyblue/go-sh
|
|
Thanks gofmt
|
|
|
|
|
|
|
|
In order to maintain a consistent format when echoing error messages,
use the Kingpin helpers to do so. Rewrite our error message code to this
effect. This has the added benefit of making our code shorter.
|
|
As far as I've been able to figure out, Kingpin doesn't have a mechanism
for dependent arguments or conditional requireds. Thus there's no way to
say "--position is only required if --write-config isn't passed".
In that case, write our own "required" check, to enforce the presence of
"--project" only if "--write-config" isn't passed. We duplicate the
message that Kingpin provides from `Required()` and leverage its error
formatting (we should probably use this for our other error messages
too).
The only difference is that `--position=POSITION` won't appear on the
first line of the Help text, which would have emphasised the fact that
it's required. It's possible to configure Kingpin's help text via
templates, but I don't think that's worth the trouble at this point.
|
|
Ensure that we're not actually submitting a time entry if the
`--write-config` flag was passed. In that case, we just want to write
the empty config file and exit successfully.
|
|
We shouldn't automatically force writing the config file. Only do so if
the user asks for it to be done.
NOTE: there's a problem here, because `-p` is required but it shouldn't
be in this specific case.
|
|
Put these constructed paths into reusable functions for easier usage.
|
|
|
|
I figured it would be a good idea to make this function and
`loadConfig()` consistent. Since `loadConfig()` is private, make this
one private also.
|
|
Now that we have a 'config.go' file, it makes more sense for these two
to live in that file.
Change `loadConfig()` to return an error instead of printing it to the
log.
|
|
If the function results in an error, print it and exit.
|
|
If no existing config file is found, write a sample config file to
XDG_CONFIG_HOME/timetasker/config.toml.
|
|
A new function that will write a new config.toml file to the
XDG_CONFIG_HOME directory. Currently it checks to see whether our config
file is present. If not and our config directory isn't present, it
creates it.
Still need to get this to actually write the config file.
Also, we won't want to call it by default in main() like we're doing
now. Will likely want to hide it behind a `--write-config` flag.
|
|
|
|
|
|
We ran into a bug where submitting "7" as the time spent would become
"700" on the site.
This was because our `n` value of 0 wasn't replacing the "." in the
string. Thus "7.00" became "7.00" after the replacement. Not right. I
misunderstood what that argument was doing and what the word "empty" in
the documentation meant.
Change the `n` value to replace all "."s in the string.
|
