Forum OpenACS Q&A: pgplsql and output parameters
TODO: output parameters
Are they not supported, and if so is there a preferred workaround?
(my guesses are writing to a temp table and returning it's name (ugh) or returning a record type?)
BTW you should probably be asking this in the OpenACS 4 design forum - I'm not sure either Dan or Vinod monitor the general forum (though they might, mind you!)
-- FIXME: last three args are also out varibles. if notify_assignee__callback != '''' and notify_assignee__callback is not null then v_str := ''select '' || notify_assignee__callback || ''('' || notify_assignee__task_id || '','' || coalesce(quote_literal(notify_assignee__custom_arg),''null'') || '','' || notify_assignee__user_id || '','' || v_party_from || '','' || quote_literal(v_subject) || '','' || quote_literal(v_body) || '')''; execute v_str; end if; v_request_id := acs_mail_nt__post_request ( v_party_from, -- party_from notify_assignee__user_id, -- party_to ''f'', -- expand_group v_subject, -- subject v_body, -- message 0 -- max_retries );
If nobody has an objections, I can move remove the acs_mail_nt__post_request call and leave a comment here that we should include the call in any callback functions that we write. I also could modify the sample code so that it incorporates these changes.
At the risk of getting further into design (sorry Don), I wouldn't remove the call completely. It's pretty useful default functionality to get an email when you've been assigned a task.
I'm not sure what the best way would be to preserve this: it would be great if the return value of the callback could be used to determine whether it had sent the message, but I don't know if that's a bad convention, or how well supported it would be across platforms.
FWIW, in another comment I saw in the code, Lars (?) suggested that notification messages would ideally be made from Tcl. This is simpler for a couple of reasons, but mainly that the Tcl code can construct an HTML notification message with subsite URLs easier. The HTML that you send out in the email will likely be reused in the workflow status pages (or vice versa).
Neophytos has volunteered to port the newer 4.3 version of workflow, so we might see this fixed when he's done with the porting effort. If not, maybe Neophytos will fix the notifications problem while he's porting the workflow package.
Until then, I've moved the notifications call into the callback routine.