| Age | Commit message (Collapse) | Author |
|---|
|
This blog post by Dimitri Merejkowsky clued me into the fact that I had
incorrectly ignored a compiler warning about an unused assignment:
https://dmerej.info/blog/post/awesome-rust-warnings/#the-useless-mutation
When I wrote that line, I didn't realise you could declare an
uninitialised variable, and definitely didn't get what the compiler
meant when it told me:
warning: value assigned to `email_eid` is never read
--> src/main.rs:102:9
|
102 | let mut email_eid = String::new();
| ^^^^^^^^^^^^^
|
= note: `#[warn(unused_assignments)]` on by default
= help: maybe it is overwritten before being read?
so I ignored the warning.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Describe the files used for authentication.
Change the file paths to use `$XDG_DATA_HOME` instead of writing the
path explicitly, as that environment variable may have been changed to
refer to a different directory.
|
|
Add description and authentication sections.
|
|
|
|
|
|
|
|
|
|
|
|
If there's only one error in the chain, it prints:
error: no matches for event ID: no matches for event ID
Now, it will print:
error: no matches for event ID
and:
error: unable to open OAuth secret file: Not a directory (os error 20)
|
|
Previously there were two OAuth authorisation prompts, one for each API
call, because each call has different default scopes.
Since we always need Event read-write access, set this as our scope for
both API calls so that we request only what the application as a whole
needs, and so we don't ask for authorisation twice (which requires
visiting a URL with one's Google account).
|
|
Because I was using `xdg_dirs.find_data_file()` to get the path to
"token.json", an error was triggered when the file didn't exist yet. It
doesn't need to exist because the program is supposed to create it, so
we can't use `find_data_file()`.
Remove the `local_data_file()` function, and instead call the XDG
functions directly where they're needed since in one case we need to
find an existing file (and error with a specific message if it doesn't
exist), and in another, we need a path to a file to create or read.
|
|
Give more context about the error produced. Trying to figure out how to
only display this if there is a root cause, but I'll work that out
later.
|
|
|
|
The "error" prefix caused a redundant message on the console:
error: error getting XDG data path
|
|
Stop using the `google-calendar3` directory and secret file and use an
application-specific one.
|
|
|
|
|
|
|
|
|
|
Didn't like the old names, too unclear.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When the `--verbose` flag is given, print the event summary and
description, time, conference info, and attendees.
|
|
|
|
Silence this warning:
warning: value assigned to `email_eid` is never read
--> src/main.rs:44:9
|
44 | let mut email_eid = String::new();
| ^^^^^^^^^^^^^
|
= note: `#[warn(unused_assignments)]` on by default
= help: maybe it is overwritten before being read?
warning: 1 warning emitted
We are reading the variable, but only if `should_read_email`.
|
|
Make the variable's usage clearer.
|
|
If the `--email` flag is supplied, parse a Google Calendar email from
standard input and extract the event's eid from there.
|
|
A base64-encoded string I tested with didn't pass the regex test, and
was treated as an event ID even though it was an `eid`.
Instead of testing whether the input is a base64-encoded string with
regex, assume it's a base64-encoded string and try to decode it. If that
fails, assume it's a regular event ID.
|
|
|
|
This reverts commits:
c2525d8e9b9bb671ce855c20f644c43e71e1e7ef
65aa6027a76a65d021a5833322b5d33143933202
It turns out we can't use the email address encoded into the base64 eid
string because it's the organiser's email address, not the invitee's
address.
|
|
Tried getting the email from the base64-encoded eid string. Turns out,
though, that the email address in the eid:
1. isn't complete (it's missing the last one or two characters of the
email address as far as I can tell)
2. is not the invitee's email address, it's the organiser's email
address
For both of these reasons (particularly (2)), it looks like we can't
actually use this method and will need to make the Event.get request
after all.
|
|
Get the user email so we can use it when patching the event. This will
allow us to eliminate the Event.get request if an `eid` is given.
|
|
|
|
Event invitation emails include event ids encoded as "eid"s. These are
base64-encoded strings of:
{event_id} {user_email}
Add a new function that decodes the ID from the base64 string if the
input ID is base64-encoded. Otherwise, return the input event ID.
|
|
|
|
Fail with an error if no action is given. Use the provided action
instead of the hard-coded "accepted" string.
|
|
I like this better. More readable to have the variable assignments in
the same column.
|
|
Decided to parse command line options manually so that if multiple event
response status flags are passed, only the last one will be used.
|
|
Allow multiple events to be handled at once.
|
