Since PR #115108 is IMAP documentation up-to-date?
kds69 opened this issue · 4 comments
Feedback
Documentation still refers to text and headers whereas this PR #115108 is aiming at removing text and headers from data event for the sake of size.
Do I get this right and below example taken from "Using events" section of the IMAP documentation is still pulling event text and headers data?
(https://www.home-assistant.io/integrations/imap)
template:
- trigger:
- platform: event
event_type: "imap_content"
id: "custom_event"
sensor:
- name: imap_content
state: "{{ trigger.event.data['subject'] }}"
attributes:
Entry: "{{ trigger.event.data['entry_id'] }}"
UID: "{{ trigger.event.data['uid'] }}"
Message: "{{ trigger.event.data['text'] }}"
...
To: "{{ trigger.event.data['headers'].get('Delivered-To', ['n/a'])[0] }}"
Return-Path: "{{ trigger.event.data['headers'].get('Return-Path',['n/a'])[0] }}"
Received-first: "{{ trigger.event.data['headers'].get('Received',['n/a'])[0] }}"
Received-last: "{{ trigger.event.data['headers'].get('Received',['n/a'])[-1] }}"
URL
https://www.home-assistant.io/integrations/imap/
Version
2024.5.3
Additional information
No response
Hey there @jbouwh, mind taking a look at this feedback as it has been labeled with an integration (imap
) you are listed as a code owner for? Thanks!
Code owner commands
Code owners of imap
can trigger bot actions by commenting:
@home-assistant close
Closes the feedback.@home-assistant rename Awesome new title
Renames the feedback.@home-assistant reopen
Reopen the feedback.@home-assistant unassign imap
Removes the current integration label and assignees on the feedback, add the integration domain after the command.@home-assistant add-label needs-more-information
Add a label (needs-more-information) to the feedback.@home-assistant remove-label needs-more-information
Remove a label (needs-more-information) on the feedback.
The example still applies, but could be improved to use the new services
The example for the last PR is here:
https://www.home-assistant.io/integrations/imap/#example---post-processing
It is an optional approach. The selection of a config entry ID works okay in the developer services or in a blue print, but in yaml this is a bit fuzzy. Should be okay in the UI though.
Closing as the IMAP documentations seems okay