Anyone know a way to get UE Script to fire when “Print” context is triggered via attaching transaction to email from the built in ‘Email’ button?

goddamit Jen, I don't even want to ask.... so Print is a UE context, does that not fire? or you want that to fire but then these other specifics too you want to validate against?

Seems doubtful that action would trigger any UEs, but I don't actually know that for sure.

I have a WFA script that does a print of the record to attach as a pdf to an email the WFA sends out. that does trigger a print action in the WF, so I assume it would for a UE too. I just don't know if the native email button does that too, but I assume it would.

Basically I’d like to fill in a non-stored field at the time of print, but we need that to work for the PDF when it’s sent via email using the “attach transaction” checkbox. The UE seems to only fire when I use the actual print button on the transaction and doesn’t fire when I send an email that has the PDF attached automatically, unfortunately.

Wtf, I didn't expect that the UE didn't fire in the email context!

I’ve encountered this before but that was many years ago, was hoping it had changed, alas, no. :(

idk if this is any use, probably not, but to clarify what I was talking about with print triggers. this code in a WFA script does trigger a PRINT event

let transFile = render.transaction({
    entityId: tranId,
    printMode: render.PrintMode.PDF
});

yeah, if you are generating the PDF via SS or using the button in the UI, it executes. Just doesn’t when using the feature to “attach” the transaction as a PDF sending an email from that transaction.

right... just spitballing, can you modify the form? remove the native attach button? put your own on there that does the render and potentially sends the email?

We need to totally do a different thing with showing the list of items on the PDF — need to do database lookups and stuff to pre-generate that whole section of the PDF (things not possible from the native Advanced PDF/HTML template). We’re already doing this for SOME content of the PDF (we generate a file - which the PDF #includes - and update it every time the SO is saved) but I was hoping to avoid having to do that for another section of the PDF.

We have a couple of bits of information that we source from a linked record on each invoice line. Right now we're fetching that information on the print event. We could store the information on the creation of the invoice instead. But I wonder what would be best performance wise. UE on print: only applies when printing. Rarely done. Multiple transaction columns, one for each field: store on creation. Though I would like to limit the number of transaction columns in the system. One transaction column with a JSON: store on creation, less columns but risk that the information is not valid JSON and would perhaps be a long text or text area field. Trickier to edit for non-techies. Performance on field types? One transaction body field with the information as a JSON: store on creation. No transaction columns.

I hadn’t thought of the “one transaction column with a JSON” idea, that might work. We have a ton of itemoptions which is the main issue (current count is 324 different item options)

Nah, I just listed that because it is our current solution too.