There is an option to persist messages on send on both RTMClient.sendMessageToPeer() and RTMChannel.sendMessage() methods via the SendMessagesOptions interface (which is the optional second parameter on both methods).
However I cannot find information on how and in what form these messages are persisted, and ultimately on how to retrieve the messages history.
Can someone point me in the right direction please? Thank you.
Apparently the feature is still in beta.
This answer is from their official repo at GitHub.
I confirmed with my colleagues, it's shown there but still in beta phase. if you believe you need this feature maybe you can try contacting sales person.
Related
I am looking into the webhook notifications and I am struggling to find documentation...
I would need to find the different payload for the "data" in the notification response...
the documentation only have one example: https://developers.coinbase.com/api/v2#show-a-notification
it is almost impossible to built an app if I need to try and see every type of notification by myself... (trial and error approach :( )
any extra resource? any help here?
thank you all
On this page, there is a link that says
See full list of notifications and corresponding payload information
But guess what, it links to the pages in your OP.
Even CB's newest documentation doesn't outline the payload until you run a sample to get the result displayed in the docs page. Here is a simple example, just click Try It to see the payload. It's not a bad thing until you need to see the payload of a signed request, then it's a PITA...
I've never used their webhooks to know how the payload differs but considering their docs you may need to run each notification to see what to expect and save the result to refer to later.
I am trying to test ODL-SDNiApp and found it not updated since Helium on this page https://wiki.opendaylight.org/view/ODL-SDNiApp:User_Guide. So, is it still supported by Opendaylight? if not, please list me some useful tools or methods for inter SDN controller communication.
Thanks.
According to the project page https://wiki.opendaylight.org/view/ODL-SDNi_App:Main, it last participated in the Boron release but it doesn't look like it's been active since. You can try the project mailing list or contact the listed committers. If it is inactive as it appears, perhaps you might want to try to reboot it.
looking at https://developers.podio.com/doc/applications/update-an-app-field-22356
as the documentation states we cannot pass the new hidden_create_view_edit attribute to the API call. (FYI: I attempted to pass it anyway but the documentation is right, it does not take the hidden_create_view_edit into account).
Can you please listen for this parameter? And in what timeframe would this become available? I need this to clone a ton of app fields with right settings.
Thanks for reporting this. It seems that we haven't included support for this specific method while implementing great new attribute hidden_create_view_edit. This is now fixed and planned for public release some time during next week.
Hello,
is it possible at all to include not only the status and most recent comment in messages sent on ticket creation and ticket changes? I'd like to see much more, say all available retrospective information, that is the entire Change history.
Maybe someone already configured Trac this way. If so, I'd be very grateful for information about that configuration, including the Trac version used with that application.
Cheers,
Thx
Trac has change listener interfaces for binding modules to act on changes, i.e. notify on ticket change. See the Trac wiki documentation for descriptions of the I***ChangeListener extension points available by now.
But you'll notice, that the data provided by these interfaces provide only limited information about the changed resource, such as ID and the changed/old vs. new values. So your request can't be solved at all by configuration alone.
While it might be possible to do more complete notification by coding look-ups for additional data in the Trac db, even this isn't possible under all circumstances. Think i.e. about ticket deletion, where everything already has gone when the change listeners are fired with the pre-defined information.
Authorize.net offers a "Silent POST" feature for their Automated Recurring Billing. It's supposed to POST data to a url of your choosing, telling you whether they were able to charge the customer, how much, etc. The problem is, it isn't very well documented.
Is there any way to test a post to that URL? I've signed up for a developer account, but there's no way to specify that URL like you could in the actual system. Hence, there doesn't seem to be a way to test it out.
If not, is there a list of possible values it could return? It appears to send x_first_name, x_amount - I've seen code that uses those values - but since I can't actually get it to send a response, I'm not sure.
Is there documentation for this feature anywhere? Or even class that implements it fully?
Better late then never: All About Authorize.Net’s Silent Post
I have not seen much on it only for AIM and SIM, you might just give them a call.
Log in to your Authorize.Net order processing account, and click on the Settings link (under ACCOUNT, in the left column). Then click on the "Silent Post URL" link in the Transaction Format Settings area. You can enter your silent post URL on the next page. The next page also contains a link to the documentation explaining the technical details. HTH
Here's a few more (somewhat) useful posts I found on the subject.
Merchant Account Services - gives some limited sample code (PHP)
Experts Exchange - lists a few helpful variables, gives an idea of what's being sent (ASP).
You still have to call your account rep for them to activate Silent Post URL with your account because that is not something that is enabled automatically
Our clients use the following tool to test silent post url requests sent from the Authorize.Net gateway.
Simply add the following url to your silent post settings and change the email address for the results to be delivered to an email of choice.
URL:
http://www.silentposturl.com/action/email/index.php?support#silentposturl.com