erp5_short_message: activate call to portal_sms.send

This way it is isolated it in a transaction that is less likely to fail. Activate with max_retry=0 and conflict_retry=False not to send activity twice in case of error.
As with email, if there was an error in activity processing, it is advised to investigate the transport logs to see if message was send or not.

bt5/erp5_short_message/SkinTemplateItem/portal_skins/erp5_short_message/ShortMessage_send.xml

@@ -81,8 +81,20 @@ if not body:\n
 if not context.getStartDate():\n
   context.setStartDate(DateTime())\n
 \n
-context.portal_sms.send(text=body,recipient=to_url,sender=from_url,sender_title=from_title,message_type="text",\n
-                        test=download, document_relative_url=context.getRelativeUrl(), **kw)\n
+context.portal_sms.activate(\n
+  queue="SQLQueue",\n
+  # We do not retry these activities not to send SMS multiple times\n
+  max_retry=0,\n
+  conflict_retry=False,\n
+).send(\n
+  text=body,\n
+  recipient=to_url,\n
+  sender=from_url,\n
+  sender_title=from_title,\n
+  message_type="text",\n
+  test=download,\n
+  document_relative_url=context.getRelativeUrl(),\n
+  **kw)\n
 </string> </value>
         </item>
         <item>

[Jérome Perrin]

@gabriel I made a mistake here. The parameter is not queue but activity.

With this wrong parameter, this was using SQLDict behavior, ie. only sending one message when multiple messages got sent in the same transaction.

[Jérome Perrin]

see 7aee478a

[Gabriel Monnerat]

Cool. Thank you to find it. I look at this but did not realize about it.

Thank you again.

[Jérome Perrin]

I rebased this in the new business template and included this fix directly in the rebased commit.