| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
Didn't really like having the application version intermixed with
regular code. This separates it and makes it easier to see.
|
|
I had forgotten that time spent can be a decimal. Make this field a
float and change related code accordingly:
* --time flag
* `NewTimeEntry()` `time` argument
* `buildSubmissionParams()` can't use `strconv.Itoa` as that's an
integer function. Instead we use `FormatFloat`. Truncate time parsing
to two decimal places because to me that seems like enough. Who's
going to say they spent `0.324` hours on something? Also, in order to
be able to properly submit values to TimeTask (at least on the edition
I use), the times must be written in European/French format, with
commas (`,`) as decimal separators. Do a string replace to get this,
as the float formatter will give us a period (`.`) separator.
|
|
If no date is passed in, default to the current date. Otherwise, parse
the date into a time that can be used to create the `TimeEntry`.
* Rename `date` to `date_str` to allow us to use `date` for the
`time.Time` that gets sent to `NewTimeEntry()`.
* If parsing fails, print an error message and exit.
* In order to use the `err` variable without redefining `date` on line
66, define it at the top of the function.
|
|
Forgot to do this in 8d802bff08826523371ab5e951d85d0c0396ccc8.
Also, the reason why I made --description's short form `-m` is because I
wanted `-d` for date. The `-m` is supposed to be like "message", like in
git-commit.
|
|
If the user specifies a project alias that doesn't exist in their
config.toml file, we should fail early and message the user about it.
|
|
Make it easier to comment out the HTTP requests when testing command
line argument parsing. To test, we're just printing the time entry with:
log.Printf("%+v\n", time_entry)
Fill in the values from our new command line argument variables. These
need to be dereferenced as they come out of Kingpin as pointers.
Haven't completely worked out how to deal with the 'date' argument yet
so leaving it for later.
Need to fail early if `project_alias` isn't recorgnised.
|
|
* Use the Kingpin library to give us POSIX command line argument parsing
with a nice interface
* Add arguments for the project alias (specified in config.toml), time
spent, date, and description
* Add a version, required by Kingpin
|
|
Make a note of the things I have in my head right now that I think need
to be done to get this project from a "works" state into a "usable"
state.
|
|
timetasker-daily
|
|
This code was used for the old multiple time entry submission version of
this program. Remove it now that the program only submits single time
entries.
We'll have similar argument handling code for user data, and the time
entry submission code is already present here.
|
|
|
|
|
|
Get rid of all the old commented Fields code. It's no longer used and is
no longer relevant.
Furthermore, since the only thing left in this file is the `Project`
struct, rename the file to 'project.go'.
|
|
These are not needed in the new world where we only submit a single time
entry at a time and entry parameters are filled in on the command line.
My guess is we'll likely have some sort of generator in the future to
create the initial `config.toml` file, but that won't contain any
logic-based data. My guess is we'll probably be able to just stick it in
a template string right inside a *.go file.
|
|
Because it makes a network request. I originally wrote this to test the
Login function while developing so it wasn't a big deal, but we really
don't want to run this type of test in normal situations.
|
|
|
|
The param needs to be present in the request in order for it to be
considered. Add it back in (we had it before
810b140b4a29b1159e76b51b90b9be7d22df1c3e) with only the `0` index being
sent in the request. This is because we're only submitting a single time
entry, the 0th one. (Other parameters end with a '0'.)
|
|
This field wasn't parsing correctly because of it's
non-automatically-parseable format.
|
|
Previously we were just printing the headers. Now print the bodies to
allow us to inspect the result.
Will probably want to add some handling that messages the user about
authentication problems.
|
|
main.go:
* Login as the configured user (haven't yet handled making `PasswordCmd`
an actual shell command)
* Create a test time entry
* Submit that time entry using `SubmitTimeEntry()`
http.go:
* Create a `baseURL` global that stores the base TimeTask URL to make
requests to
* Return an `http.Client` from `Login()` that can then be passed to
`SubmitTimeEntry()` to reuse the login session. Needed to return a
pointer to allow us to return `nil` from the first error handler in
the function. Don't like that at all, but we're just trying to get it
to work at this point.
* Actually make an HTTP POST request in `SubmitTimeEntry()` using the
given HTTP Client and existing time entry submission params
* Take an `http.Client` argument in `SubmitTimeEntry()` to allow us to
use a logged-in session to POST. Otherwise we'd be locked out.
* Change `v` variable to `values` in `SubmitTimeEntry()` for better
readability
|
|
Now that `Profile` and `Project` have been subsumed into `TimeEntry`
(f017c462593496efbc0810ec2603da49a2e3d9d8), these arguments should no
longer be here and their data should come from `TimeEntry` instead.
|
|
Time spent on a project can be variable from day to day. The time
shouldn't be stored on the project, and should no longer be passed in
config.toml. Instead it should be a part of `TimeEntry`, which it now
is.
|
|
A new function that creates a `TimeEntry` build from a `Profile`,
`Project`, and a few other parameters. Makes it a bit easier to create
`TimeEntry`ies.
Additionally, add a `PersonID` field to `TimeEntry` so we can pass it
around as a self-contained thing without worrying about having to pass
a `Profile` along with it.
|
|
A slightly altered function that only submits a single time entry and
uses our new `Profile`, `Project`, and `TimeEntry` types.
|
|
Require the config.toml file to come with a `[profile]` hash. This
allows us to get the "person_id" for correct submission to TimeTask.
Additionally, add a TOML tag to `PersonID` in `Profile` to allow it to
be decoded.
|
|
Otherwise the TOML decoder didn't know how to parse it.
|
|
Change the function to use our new `TimeEntry` type, which doesn't
demand asking for IDs as it already has them built in.
Additionally, remove the loop here as we only want to submit a single
time entry at a time.
Add a new `Profile` type that holds onto the user's person_id. Forgot
that existed. We'll have users fill that into their config.toml file.
|
|
Uncomment these functions. Looks like they'll still be useful after all.
Just need a little munging to fit them into the usage of submitting a
single time entry and using our new `Project` and `TimeEntry` types.
|
|
Change [Client, Project, Module, Task, WorkType] fields to `int`s
instead of strings.
In the new era, with config2.toml, these fields will be populated
directly with the proper int IDs from TimeTask. Thus these fields need
to be `int`s.
Get rid of the `UnmarshalYAML` function as in the new era we won't be
submitting time entries by YAML file. Instead they will be submitted
directly via command line arguments (plus the IDs coming from the config
file).
|
|
|
|
This corresponds to a "project" entry in the new config2.toml file. (See
13c84cd9973458750305c72a919cf921d9b22b04).
Instead of decoding generic `interface{}`s as projects from the TOML,
make them a real type.
The reason why we're using `int`s where we used to use strings is that
the new TOML format will have users write IDs directly in the config
file, instead of having the program automatically search for those IDs
and use them as we had previously designed. Maybe we'll bring that
functionality back at some point, but for now it's too bothersome to
implement and I don't consider it worth the trouble.
|
|
Half get rid of a lot of code. I don't like and don't want to use our
old field types. Get rid of them and the code in 'http.go' that depends
on them.
Also get rid of the time entry submission code in 'main.go' as that's
going to be redone.
|
|
* Get rid of the 'yaml' import since we're now using 'toml' instead.
* Get rid of commented code that's no longer relevant.
* Get rid of test code that checked that the config loaded
correctly.
|
|
Construct a new config format, written in TOML. Read that format in
when starting the program. This new format has the benefit of using
project name aliases as keys. The goal will be to allow users to send
one of those aliases as a command line argument to the program,
and thus to have the program post a TimeTask entry for that project.
Here's an idea of what the new format looks like:
[auth]
username = "example"
password_cmd = ""
[projects.myprojectalias]
client = ...
project = ...
module = ...
task = ...
work_type = ...
time = 7
billable = true
[projects.project2]
client = ...
project = ...
module = ...
task = ...
work_type = ...
time = 7
billable = true
Eventually, we'll need to remove the `interface{}` from the
`Projects` map value and replace it with a real type, but this was just
to test that it was possible to get us a nice map from the TOML.
|
|
Add info about the project, the fact that it's been abandoned and why,
and license information.
|
|
|
|
Use a GitHub path instead of my custom project path to allow us to
publish the project.
|
|
Get Monday's date from the current week using the When library (which
provides natural language date parsing, making it super easy to get a
time object for Monday). Then when creating the `TimeEntry`ies for the
generator, fill in Monday–Friday's dates in the output.
|
|
A function to generate a weekly time sheet.
Add a new `defaults` key to the config.yml file. Looks like this:
defaults:
client:
project:
module:
task:
work_type:
time:
billable:
This will be used to fill in default values when a timesheet is
generated.
|
|
The date is allowed to be empty in the config defaults hash. Don't error
if it is.
|
