File Attachment Support Added to Apprise #173
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description:
Related issue (if applicable): fixes #172
Completion Status
Notifications Enhanced for Attachment Support
The following notifications have been updated to support attachments:
Checklist
flake8
)Details
The ability to attach one or more files to a notification (provided the service has been enhanced to support this new feature). Here is an example of an email I set to myself using the following command:
The result looks like this (for Email):
![Screenshot from 2019-11-11 11-54-01](https://user-images.githubusercontent.com/850374/68605442-6679c900-047a-11ea-87df-bdc40d16993d.png)
Similar to how the Issue (#172) was written, this can all be done through the API just as easily:
Sending more than one attachment requires you to use the AppriseAttachment object:
Similar to how the Issue (#172) was written, this can all be done through the API just as easily:
Some other things to note:
http://
,https://
, andfile://
. Absolute and relative paths to locations are internally treated asfile://
automatically.Caveats:
?dl=1&lang=en
). The arguments within an attachment URL are currently used to pass configuration back to Apprise.name=
,mime=
,cache=
, and/orverify=
then they will never make it upstream (as these are reserved for Apprise).Attachment URL Arguments
Everything passed as an attachment is treated as a URL at the end of the day. If you pass in
/path/to/your/attachment
to Apprise, this actually just gets prefixed (behind the scenes) with file:// and referenced asfile:///path/to/your/attachment
.If you want to pass in options, you do this though arguments on the URL.
name=
Allow you to over-ride the filename (from it's source) before passing it to the target notification service(s):
http://host/path/a-file-name-you-do-not-want.jpg/?name=apprise.jpg
: the following Apprise Attachment URL would haul down the content located ashttp://host/path/a-file-name-you-do-not-want.jpg
and rename it toapprise.jpg
for the purpose of resending it through notifications.file:///absolute/path/to/camera/images/DSC_000.jpg?name=FamilyPhoto.jpg
: The same effect takes place for using files.mime=
All files have a mime-type associated with them. A mime-type looks like
image/png
for example for PNG images. Apprise is smart enough to figure the mime-type out on it's own in most scenarios. Mime types really only play a big roll in the presentation side (at the notification service level). Hence telling Slack ahead of time it's getting an image vs a sound clip changes the rich experience you get presented. You can over-ride the mime type (if you don't like the way Apprise got it) by specifyingmime=
on your URL:file:///path/to/content?name=Report.yaml
: In this case Apprise will be smart enough to determine that thecontent
is actually a YAML file which has a mimetype oftext/x-yaml
. Without knowing thename=
value specified Apprise couldn't have otherwise determined that from justcontent
.file:///path/to/content?mime=text/x-yaml
: In this example (very similar to the above), you let Apprise know ahead of time what the mime type is.In most cases, you will seldom ever have to override and/or specify the mime type.
verify=
This is used for
https
requests only at this time. It is used to validate that the remote host name actually has a valid SSL Certificate. If you're running Apprise in a closed network where it can't verify the hostname of a secure website, you will need to set this to False.verify=
is a common parameter that can also be used with Apprise Notification URLs and Apprise Configuration URLs as well. For consistency, it is also used here if needed.cache=
By default this value is set to Yes if not otherwise specified. Possible values are:
Yes
orNo
)At the time of creating attachment support to Apprise, It only recognizes the following URLs (as identified above):
file://
,http://
, andhttps://
. Thiscache=
directive has no impact on local files (file://
) as they never expire. However for files that have been retrieved remotely; sometimes we want to invalidate what we previously downloaded before posting the same attachment again. A use case for this could be a security camera. You can appoint Apprise to it and ensure that each time a notification is sent, an updated image is retrieved.Setting the the
cache=
value to zero (0) orNo
have the same effect.