gmailctl should not try to create "INBOX" label about gmailctl HOT 6 CLOSED

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.

from gmailctl.

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.

from gmailctl.

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.

from gmailctl.

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

from gmailctl.

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.

from gmailctl.

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.

from gmailctl.