My goal is to add an attachment names xyz.pdf in Gmail from Google Drive as an attachment.
Plan is to use Autopilot, some {tab}, {key}s and search for the document xyz.pdf. This plan fails, since Text Blaze continues with its Autopilot in the email, instead of in the drive window. {Click} also fails to click the drive icon, but as a workaround I use {key }
How can I change the html window where Autopilot is active? See the image attached to see the problem visually.
When you insert a Text Blaze snippet, you cannot change window focus mid-snippet. However, you could break you snippet into two parts - one for the gmail window and one for the Google Drive window.
Thanks for the clarification of what is possible with snippets.
About the workaround: breaking up the snippet is doable if you want to insert only one file automatically with one snippet. If you want to insert three files automatically with one snippet, It will have to become 3x2=six separate actions and four snippets: one for triggering the Google drive which can be used three times, and three for each of the three files. Remembering these snippets kinda beets the purpose of automation.
Is changing window focus mid-snippet a feature that can be made in the future, or is this theoretically impossible with Text Blaze? And if it is possible, would you think there is any possibility of adding this in the near future?
@Cedric_Debono_Blaze Thanks for giving this improved workaround with formmenu. It indeed removes the need to remember three additional snippet codes (but adds manual clicking).
We currently use Blaze Today actively for two weeks now and really enjoy the speed up it brings compared to regular Gmail templates. If at some point in the future it would be possible to add attachments within Gmail automatically as well, I would greatly appreciate that.
You could probably use {site: text; selector=} to search for certain keywords inside the body of the email to which you're replying, and get the formmenu to trigger a particular suggestion based on the findings. However, things might get complicated really quickly with an approach like that. But it might be worth a shot. It could save you the hassle of having to pick an option every time.
As for your suggestion regarding Drive attachments, please post it in the "Feature Ideas" forum so we can have it on record there and assess viability:
Since we're on topic, could you elaborate a bit more on the actual use-case for this? I understand the process and outcome you would like to achieve, but I'd love to know more about the context. This would help us develop the feature in a more relevant way.
@Cedric_Debono_Blaze Sure: our sales department sends out emails with information about our products. Each email is based on a template and attached are at least three PDFs, which depend on the product.
Currently /snippertXYZ inserts the template for product XYZ in an email written in GMail. We then manually drag and drop the documents to the email. But since most of the documents are always the same and you don't want to forget any document, automation is preferred. Ideally /snippetXYZ does not only write the email partially, but also adds the three standard PDFs.
@klaas, as an alternative solution, have you considered uploading the pdf's to the company's domain and just adding links to them accordingly in the email? I'm getting the impression these pdf's don't change very frequently, so it could be a very practical solution.
Additionally, since you're sending these pdf's out, I'm guessing it's not sensitive information so it should be fine on a public domain. You could ask your systems administrator to make them non-indexable too, so they won't be discoverable via search.
@Cedric_Debono_Blaze, I appreciate that you keep thinking of possible solutions. Unfortunately, two out of three documents do contain sensitive information that can't be made public. A workaround for that would be to add the documents to GDrive and share them as a link which can only be opened if you have the exact link.
But clients prefer to have a PDF, since it can be saved and shared easily. Clicking a link happens less often compared to opening a PDF. Also PDFs keep working two years later, whereas a link could have changed due to an update.
{note: trim=yes}Click on the attachment button in the Gmail compose box{endnote}{click: selector=td.bzE div[command=docs]}{key: enter}
{note: trim=yes}Wait for the attachment frame to load{endnote}{wait: delay=+5s}
{note: trim=yes}Click into its search field{endnote}{click: frame=top; selector=iframe[src^="https://docs.google.com"] |> input + input; maxdelay=+10s}
{note: trim=yes}Insert the search term and hit enter to search{endnote}search term{key: enter}
{note: trim=yes}Select the first result by clicking it after it appears{endnote}{click: selector=div[id][aria-selected=false][data-target]; maxdelay=20s}{key: enter}
{note: trim=yes}Click the "Add as link" button{endnote}{click: xpath=//*[contains(text(), "Add as link")]/parent::button; maxdelay=5s}
Thank you Gaurang_Tandon, for making this example.
Unfortunately, the line to select the search field doesn't work.
{click: frame=top; selector=iframe[src^="https://docs.google.com"] |> input + input; maxdelay=+10s}
If I manually replace it with a click element in a CSS field, I get:
{click: frame=top; selector=#z2rz21b55u1l |> input + input}
which also doesn't work, because the name of the selector keeps changing.
Navigating with buttons instead of clicks still has the old problem that it is in the wrong iframe.
As you can see, in my case it starts with "https://docs.google.com", hence that's what I used in my selector. Please share with me the screenshot in your case, so I can better understand what to use in your case.
