So I am trying to understand the workflow in kicking a user from a channel. I have a command I can issue to the channel #kick username. This is handle by a handle in which parse the message and will detect is a command. That will call the kick function in my channel. My issue is how I actually make the user leave. There is no such thing as Endpoint.Broadcast with a leave event like we have for disconnecting a socket from everything.
I've been told to use a Endpoint.Broadcast an event like kick and use a handle_out to intercept it. Well even if I use it, how is this disconnecting the user I want specifically to be kick as an admin.
Related
I have a very simple alert mechanism to alert drivers "in-the-field" when a new pickup has been assigned to them. I have had an instance twice where a driver has responded with a STOP and became un-subscribed. Once discovered we acquired the proper opt-in documentation from them. Is there any way to re-subscribe a user that opted out and changed their mind on receiving the messaging. i.e. they issued the STOP to the incorrect SMS. And have deleted the original message to START. Or do I need to code something for them to opt back in
My SendGrid provides a method to remove suppression from email but am not finding anything like that here in Twilio.
They need to send a START to the number they previously opted out of, this is currently a requirement. You will also get an error when trying to send messages to them, to alert you they opted out.
Error 21610 - Attempt to send to unsubscribed recipient
I want to connect random users on a call (1 on 1 only) but that results sometimes in call collision. Steps that I took so far are:
On call button press I create a new session and try to connect with other users
The opponent users receives that call and has to accept or reject it, but in the meantime he is also waiting for accept/reject from the call that he made.
Basically everyone will end up calling someone and I am unable to think of a strategy where the system doesn't get overwhelmed with call requests.
Maybe someone who had a similar issue could help me with this problem
I have a Twilio Studio flow that uses the "Gather Input from User" during an outbound call.
I have widgets following all possible outcomes, including "No Input".
However, I have discovered that if the user hangs up during this step, the flow ends.
I need to capture the fact that the user hung up, but I can't figure out how.
Any suggestions?
Twilio developer evangelist here.
For an outbound call from the Studio widget there is no way to capture status events as you would for a call normally. There are two workarounds though.
Firstly, if you are recording the call then you can set the recording status callback, which will notify you once the recording is ready and thus the call is over.
Alternatively, you will need to poll the Studio REST API to keep an eye on running executions and when they finish.
I am working on an ios app using parse as a backend.
I am having an issue where i am putting all of my save calls into a queue when i am offline and then using reachability's "kReachabilityChangedNotification" to trigger them as soon as they come online.
This usually works very well and is, for the most part, more preferable to parse's saveEventually function. However, it runs into trouble when the user is logged out before they come back online causing the save call to fail as we check for users in the before save.
So i was wondering if anyone had any ideas for how to listen for when the user is logged in/out, so i can also trigger the queue based on that.
You could check that currentUser is not null on the Client side, before the save. Also , if the user logs in and out via the app you can do that logic there.
I have to add e-mail notifications to a client server application.
Notifications happen as the user do some particular action on the client UI.
If I had a middle tier or a service running at server I can imagine how to do it:
1) I simply create a DB tables with "pending notifications"
2) as a user does an action that generates a notification I add a record to the table
3) serverside I would continuously try to send those mails and removing them from the table once sending is succesful
Now I cannot do this now, I have a plan to add a service later on, but for now I must go the quick and dirty way.
So somehow what I was thinking to is to implement something like this:
1) as a notify-worth event occurs at client, the same client (my exe) tries to send the notification, upon failure it will log the notification in the "pending notifications" table (failure can be becuase lack of internet connection or any other problem)
2) I add a Timer that will work from any client machine to check for pending notifications. If there are any the client will try to send the e-mail (using a transaction: I will mark a field as "TryngToSendFromClientX" and in case of failure I will reset that field to NULL)
I think this approach would work, it has obvious limitations (if after failure no one logs into the system, no notification will be sent - same would be if service goes "down"). But can you comment on this approach and suggest a better one?
Additional notes (to better understand the scenario):
a) Note: all notifications are sent from the same e-mail account.
b) I don't need to keep track of who sent the e-mail.
c) the problem of creating the service now is that it will basically complicate significantly deployment and I need to create tools for monitoring the status of the service. Something that I will do in future but not now, in future I have plan to add more functionality (not only sending notifications) to the service, so in that case it makes more sense to create it.
d) I will send e-mails by using Indy components and SMTP server.
If you are not willing to create the service now, I think you are stuck with the scenario you describe. There are some things though you could do to circumvent the problem of no user firing up the client anymore while there are still pending messages.
You could add a commandline utility (or commandline parameter as bepe4711 suggested) that will only check for pending messages and try to send them.
Add this commandline utility to the StartUp folder or Run key in the registry. This way messages will at least get sent when the computer restarts, even if the user does not fire up the your app.
Add a scheduled task to run this utility at least once every day. The scheduled task can be added by code or by your installer.
If you do both, you will only have to worry about pending messages of users that never start their computer again.
Perhaps you can add a parameter to your client which causes it to just look at the pending notifications and send them. After this it can terminate itself. It will just act like some kind of service.
Then you install the client on the server and start it every x minutes.
I do something very similar to the approach you describe. Instead of sending emails I need to call a web service. My application is installed on several laptops and they are commonly not connected to any network.
When my application raises an exception I collect various bits of information including user comments and screen shots. Then I attempt to send this to our web service. If by chance the web service is not available. (i.e. not connected to the internet or web service is down) I write the results to an XML file on disk in the User Profile (App_Data) directory.
The one major difference is I don't poll to check to see if the server is up. I attempt to send them again on the startup of the application.
If both Systems are running on Windows, have a look at MS Message Queue. It is designed to send notifications to systems, which are not allways online. I did it in .Net, there are already easy to use classes implemented. Not sure about Delphi.
Latest version of Windows uses much more the Windows Task Scheduler, and now task can be fired on event (i.e. when a network card gets connected...). You could write a separate utility that tries to send pending notification, even if noone is logged in.