It is unclear what support is intended for Contact group labels in the Bridge. They are processed by the handleLabelEvents function in user/events.go, but are not properly loaded when the Bridge starts from the constructor in user/user.go. So, I am not clear if the support that exists is intentional or just a byproduct of handling events from the API.
Expected Behavior
Events related to Contact Group adds, updates and deletes would be ignored by the handleLabelEvents function in the Bridge.
Current Behavior
On a Contact Group add, a new mailbox is created in the bridge, updates are applied and when a delete event occurs, the mailbox is removed. As a result of the fallthrough in getMailboxName in user/events.go, these labels are added without a parent, and should they show in the mail client, display alongside the system mailboxes.
Possible Solution
The solution depends on the intended support for these labels.
The lack of code related to these labels suggests that they are not supported. Therefore, the handleLabelEvents function could simply ignore these events by checking for the event.Label.Type. Delete comes without a type though, so ignoring it would either require more changes or, as letting it get processed does not have obvious negative effects, allow the delete event for these labels to get processed normally.
Alternatively, adding support to load this label type in the New constructor for a User in user/user.go, would at least get these reloaded into apiLabels on startup. Then, they could be dealt with like the All Mail label, with an option in the UI/CLI to control the display (or not) of this label type.
It is unclear what support is intended for Contact group labels in the Bridge. They are processed by the handleLabelEvents function in user/events.go, but are not properly loaded when the Bridge starts from the constructor in user/user.go. So, I am not clear if the support that exists is intentional or just a byproduct of handling events from the API.
Expected Behavior
Events related to Contact Group adds, updates and deletes would be ignored by the handleLabelEvents function in the Bridge.
Current Behavior
On a Contact Group add, a new mailbox is created in the bridge, updates are applied and when a delete event occurs, the mailbox is removed. As a result of the fallthrough in getMailboxName in user/events.go, these labels are added without a parent, and should they show in the mail client, display alongside the system mailboxes.
Possible Solution
The solution depends on the intended support for these labels.
The lack of code related to these labels suggests that they are not supported. Therefore, the handleLabelEvents function could simply ignore these events by checking for the event.Label.Type. Delete comes without a type though, so ignoring it would either require more changes or, as letting it get processed does not have obvious negative effects, allow the delete event for these labels to get processed normally.
Alternatively, adding support to load this label type in the New constructor for a User in user/user.go, would at least get these reloaded into apiLabels on startup. Then, they could be dealt with like the All Mail label, with an option in the UI/CLI to control the display (or not) of this label type.
Possible Implementation