gmailctl should not try to create "INBOX" label

[pprkut]

I have a filter rule that sets the label INBOX/Jira/<Project>. When fetching emails via IMAP, this creates a folder hierarchy like Inbox -> Jira -> <Project>.
When using automatic management of labels with gmailctl, gmailctl tries to create the labels: INBOX, INBOX/Jira and INBOX/Jira/<Project>. However, the API complains that INBOX isn't a valid label:

Error: creating labels: creating label "INBOX": googleapi: Error 400: Invalid label name, invalidArgument

IMHO it shoud just skip that label, since it doesn't need to be created. For now the only way (that I can see) to work around it would be to manually list the labels, or at the very least, manually create the "toplevel" labels first.

[mbrt]

How do you create the Jira label to be under Inbox through the Gmail UI? I don't see a way to do it. I also can't create a label called INBOX through the UI, which matches the behavior of gmailctl.

If it's just a top level label you could just remove the INBOX part in the config.

[pprkut]

I just tried using the Gmail UI, though normally I do everything from within my mail client. IMAP doesn't know about "labels", it just knows folders and Gmail translates between the two internally.

In the UI, all subfolders of Inbox show up with INBOX/ as part of the label. So a Jira subfolder of Inbox would show up as INBOX/Jira.

[mbrt]

I see. As I suspected, the actual label is INBOX/Jira (i.e. a label with a slash within). I see a couple of ways forward:

You could manually list your labels like so:

labels: [
    { name: 'INBOX/Jira' },
    { name: 'INBOX/Jira/foo' },
    // ...
  ],

Or if you're currently using lib.rulesLabels(rules), you could just modify the library function (in gmailctl.libsonnet) to ignore the INBOX prefix or remove the extendWithParents part.

I'm hesitant to modify the behavior of existing functions, unless there's a very good reason as they tend to break existing users. I feel like your particular use case should be easy enough to handle on your side.

[pprkut]

Generally, I'd agree.

My thought here is that this is a pretty simple case that would be broken for any user wanting to do this already, but also shouldn't impact anyone who doesn't need it.
All that's really needed would be some logic that prevents a plain INBOX label to show up in the labels list when using the library function. Like you mentioned earlier, there's no way to create such a label, through the API or through the UI.
It would break for people that rely on this throwing an error, like perhaps in tests? I'm not sure how common that would be.

I changed the library function to do

local flat = std.flattenArrays([extend(l) for l in labels]);
std.filter(function(f) f != 'INBOX', flat),

That seems to do what I'd want

[mbrt]

Yes, I agree that this seems like it would not be a big breaking change.

One thing to keep in mind is that there are a bunch of special labels, and some are not even documented: https://developers.google.com/gmail/api/guides/labels#types_of_labels. To fix this properly we would have to account for all these cases (and keep them in sync).

In general I feel like it's strange to have label names starting with INBOX/, so I'm reluctant to complicate things to accommodate this case.

Maybe one more potential way forward is to have a variant of rulesLabels that doesn't create sub-labels automatically. This seems like a generic enough use case.

[github-actions]

This issue is stale because it has been open for 30 days without activity.
This will be closed in 7 days, unless you add the 'lifecycle/keep-alive' label or comment.