Auto-create missing labels on apply

[slippycheeze]

I just applied my shiny new rule and ...

error adding filters: error exporting filter #0: error in export action: label 'redacted' not found

...ouch. It'd be nice if labels could be auto-created when required.

[dhouck]

Not exactly related, but close: Suppose I already have a label foo and filters that apply this label. Is there any way to change the label name to bar more simply than:

1. On the web UI, rename the label
2. In my gmailctl config, rename any instance of the label (hopefully I put it in a variable name if it’s the sort of thing I thought I might rename)
3. Verify that gmailctl diff is empty

I don’t think there is, and I'm having trouble even coming up with a way to potentially simplify the process, but if there is one I haven’t thought of I’d like to know.

[mbrt]

So, this issue is nice to have indeed, but you run into all sorts of problems if you want to do it properly, and that's why I decided to put it off for now.

As @dhouck pointed out, renaming by hand is painful, but how do you know if a label has been added vs. renamed? This could open a can of worms.

Perhaps the only proper way to do it would be to completely take over the labels management, and add a new section of the config specifically for them. This is however quite some work and it also involves a change of the config format.

[slippycheeze]

The minimal implementation, where it simply creates the label specified in the configuration, and lets the user deal with complexities such as removing them, renaming them, etc, seems like a useful single step to me.

Opt-in, if you are concerned people expect an mind-reading-complete version, but I'm comfortable that I shouldn't run gmailctl while messing around with labels on the gmail side – and that I can't expect gmailctl to reverse-engineer those changes and apply them to the jsonnet source.

I'm way too familiar with "properly or not at all", but I'm trying for more pragmatism these days, and this'd be the pragmatic step one toward a proper solution.

[mbrt]

The problem is not implementing features incrementally, it's with surprising features. If you rename something in the config, it's now reflected correctly to the Gmail settings. If you implement the label create feature as you suggest, renaming a label in the config will just create another, and assuming a filter is targeting that label, old mails will remain in the old label, while new ones will be in the new. A user expects a rename, while they are getting two labels. This is surprising. Funny thing is that to fix this they'll have to go to the UI, delete the new label and rename the old one. Another problem is that typos will translate in new (unwanted) labels, that could mess up your inbox in subtle ways.

I however realize that when you are building your config from scratch you have to create a lot of labels from the UI, and that's annoying. I'll keep this open since it's a nice to have. Maybe I'll find a nice way to make this not surprising or error prone, and so could be done.

[slippycheeze]

I however realize that when you are building your config from scratch you have to create a lot of labels from the UI, and that's annoying.

I'm not, and I don't expect the rename, but I'll also own this: when I design UI and UX, it produces results that only a software developer could love, so I'm not going to claim that other people would have the same expectations.

I'll think about this, too, and see if I can figure something else out. I understand and respect your position, and declining the partial implementation on that basis.

[dhouck]

I think the only way to do this sensibly is twofold:

• When trying to apply a config, if there are missing labels, output something like Label "foo" does not exist. Create it? [Yn], possibly showing the relevant portion of the config first. If no, abort reconfiguration.

  • Optional typo detection:

    
    Label "foo" does not exist. The most similar labels are:
    
    - fog
    - food
    - fool
    - goo

  Create label "foo"? [yN]

  
  (No, I don’t know why this hypothetical person has a label for goo-related emails)
  
  This would help prevent users going "Yes I want that label; I thought I already created it" and then accidentally having two labels, but AIUI actually fixing the configuration would still need to be done manually.

• Add another command, say gmailctl label, with subcommands create <name> and edit <old_name> [--rename <new_name>].
  • Optionally, this command could also support other options to gmailctl label, like --text-color, --background-color, --label-visibility=(show|hide|if-unread), and --message-visibility=(show|hide). Those might be a bit beyond the scope of the program, though, and are definitely less useful features than the core creating/renaming labels.
  • If you don’t want to support any sort of label managing beyond the basic create/rename, then the syntax gmailctl label edit <old_name> --rename <new_name> is a bit cumbersome and gmailctl label rename <old_name> <new_name> might be preferable..

This way you don’t need to switch between the GMail web UI and command line, and it still has adequate typo prevention.

[mbrt]

@dhouck This sounds reasonable. We could have a bit of a problem showing this when multiple labels are added, but this looks like a starting point.

Perhaps this issue should be split in two:

• the label command as described
• the auto-create for the labels. Maybe also guarded behind a flag as @slippycheeze previously suggested. Something like gmailctl (edit|apply) --create-missing-labels

[GMNGeoffrey]

Just chiming in that this feature would indeed be lovely to have. As a previous inbox user that got burned by its turndown, I really want to recreate something approaching bundles, but my idea for how to do so involves generating a lot of labels in pairs (e.g. "foo" and "foo (done)"), which is painful to do manual. Having auto label creation would allow me to finally get around to doing this cleanup, whereas currently gmail is choking on my labels containing very large numbers of emails. Bonus points if the labels could be entirely config-based for showing/hiding, etc, but I think it wouldn't be too painful to do that manually in the UI once I'd created everything

[mbrt]

I agree that this is important. I'll get to it eventually, but instead of making an incomplete solution I would prefer to make the thing 100% declarative. My own bad experiences tell me that half-baked solutions tend to give birth to all sorts of scripts and workarounds client side...

[mbrt]

My current idea is to add a section in the config with the complete list of labels. If this is present, then it is synced with the Gmail settings. To ease the migration I can also extend the download functionality. Perhaps the color can come at a later stage, but it should be easy to add.

[mbrt]

Perhaps the error prone situation of a label rename can be successfully detected and prevented. Before doing any changes I can check for every label if:

• the label has been removed from the config, and
• the label contains messages (the APIs return this information)

Then this was either a rename or a removal. Since we don't know what to do, we should fail with a message and suggest to either:

• Remove all the messages from the label, if a delete was intended, or
• Rename the label manually in the Gmail UI, if that was the intention.

If the label instead didn't contain messages, then we can safely delete it.

[legeana]

Auto-creation could also be solved with complete list of labels approach suggested by @mbrt by having a jsonnet helper function that iterates over rules and generates a set of labels, something like:

labels: lib.allLabelsFromRules(rules),
// or
labels: ['manual', 'list', 'of', 'labels'],

[mbrt]

@legeana Very good idea! This could be added to the library, so you don't have to maintain them manually.

The only caveat happens if you have labels that you apply manually (I do). In that case they won't appear in any filter and so you have to extend that list manually.

If someone wants to maintain the list completely manually (e.g. to protect themselves from typos in the label name), it's also possible.

Thanks for the suggestion!

[legeana]

you have to extend that list manually

I mean... labels: lib.allLabelsFromRules(rules) + ['manual', 'labels'];

=)

[mbrt]

This has been a little bit more work than I wanted, but this feature should be basically complete in PR #68. README is also up to date there.

I did some unit testing and I tried it out with my own configs, but for sure it might still have some bugs. If someone wants to give it a try and give some feedback it would be really nice!

I will probably merge it next week.