| Age | Commit message (Collapse) | Author |
|---|
|
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 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.
|
|
These tell the Time Task form endpoint that we're submitting a
multiple-time submission request.
|
|
Because `strings.Itoa` is so much easier to call than
`strconv.ParseUint`, and I needed to parse ints into strings to build
the URL params in `buildSubmissionParams`
(17f4ecc63615e3f3bef21a80f15e7c7b0e0cffa1).
|
|
Function that takes a list of `TimeEntry`ies and builds the necessary
URL params for submission to the Time Task form endpoint.
|
|
Not relevant. See 89f766854443a6f7ae20c330547083fd0e075ba9.
|
|
We want to be able to get Client, Project, etc. objects given their
name. These functions will look through the fields or objects containing
a list of the thing looked for and return if if its name matches the
search string.
Originally had the idea to generalise the body of the function, but had
trouble making the types generic. Still on the table for later if we
want to deduplicate the code. For now I'm leaving in the repetition
because it works and I don't care with this project.
|
|
Embedding this struct prevented us from correctly unmarshalling data
into them. This is because they need to be created like:
Client{IDName{ID: , Name: ,}}
The fields can't be added in directly.
Save ourselves the headache and just manually repeat the fields. So that
importing works right.
|
|
Forgot to add this field originally. Do the same as when we added the
`Time` field.
|
|
Fix 7a8db5312bbb43c986fbae7aa14960e22080b03b to ensure that the `Time`
field actually gets unmarshalled into `TimeEntry` structs.
|
|
We'll be needing to refer to these fields as named types, so create
types for them and reference them in the config object.
|
|
Include billable hours field.
|
|
Expect a timesheet file as the last argument to the program. Parse the
contents into `TimeEntry` objects. `TimeEntry`ies will then be able to
be POSTed to Time Task to submit times.
The time entries input file is a YAML document in this format:
- client: A client
project: A project
module: A module
task: A task
work_type: type
date: 2017-03-06
time: 7
billable: true
description:
It contains an array where each element is a time entry.
Had a lot of trouble parsing the date into a `time.Time`. Finally
realised that my first and biggest problem was somehow I was importing
`yaml.v1` instead of `yaml.v2`, and thus my `UnmarshalYAML` function was
never getting called.
Wanted a way to get the time as a string and parse it myself into a
time. At first tried using an `UnmarshalText` function:
type Time time.Time
func (t *Time) UnmarshalText(text []byte) error {
parsed, err := time.Parse("2006-01-02", string(text))
if err == nil {
*t = Time(parsed)
}
return err
}
But in order to do that I had to make a type alias to `time.Time`. Doing
so was not ideal, because then I'd have to convert my `Time` into a
`time.Time` any time I wanted to use it for real.
Ended up going with a suggestion from here:
https://mlafeldt.github.io/blog/decoding-yaml-in-go/
Creating an auxiliary struct in `UnmarshalYAML` to unmarshal the date
into a string and then parse it myself as a date. I don't really like it
because it's a lot of ceremony just to parse one type myself, but can't
come up with a better solution right now so there you have it.
|
|
|
|
Verify errors and check the response body to ensure successful login.
|
|
Fill in the `Login` function to actually log in to Time Task. Pass
credentials in via test command flags.
Referenced https://gist.github.com/varver/f327ef9087ebf76aa4c4 for the
cookie setup.
|
|
Make a sample GET request using `net/http`.
|
