We use AC 5.13.60. We have a Webhook configured to notify a 3rd party about new discussions.
When we were testing this, it was working properly but in 'real life' it doesn't. The webhook doesn't even get triggered when a new discussion is created or a comment is made.
This is a major problem because every project only has 1 project leader and if he is in vacation, nobody gets notified about new client requests.
Has this webhook stopped working in the latest release?
BTW: It would be great to see events regarding discussions in Zapier as Trigger and not only Tasks! So we could simplify the workflow.
Thanks for any feedback and best regards
Lukas.
Related
I want to learn about FIWARE. I found out about FIWARE labs and tried to register in it. I was unable to register with them.
Unfortunately after repeted attempts, I was not able to register with the same. Everytime i would be getting a varification mail and every time as soon as i reply i would be getting the reply that that mail is held up for review. Can anyone help me on how to solve it.
On the introduction page for the 'APIC Test and Monitor tool' one of the listed features is 'Get alerts on your API Health'. However once inside the tool I can't find any reference on how to generate alerts...
Is it already possibble? Or just an idea for the future?
Great question, thank you for asking. You are absolutely right, we are working on shipping notification/alerts as a pluggable ecosystem. We are building a fully featured API and Webhooks, any platform that leverages an API can be used, as well as email and SMS.
Out of the box we will provide the most popular plugins such as the following:
Slack
BigPanda
HipChat
StatusPage.io
JIRA
Twilio
DataDog
New Relic
Elastic
You will also be able to create alert groups, ex. specific tests/monitoring can be mapped to specific groups.
Will update this space when it becomes available. Your feedback is helpful, what is your preferred method to be notified by?
Thanks!
I'm currently trying to develop a Chrome extension which can receive notifications using GCM. When the extension is first installed, I register it using chrome.gcm.register(['my_sender_id'], function(registration_id) { console.log(registration_id); });.
I would like to send push messages to everyone who has the extension installed. However, the problem is that GCM requires you to specify the registration ID's of everyone you want to send the message to; you can't just send it to everyone who's connected to the sender ID.
While it would be possible to push the registration ID to a database when the extension is installed, and then consult this database each time I want to send a message, this solution seems sub-optimal (also from a security point of view, since the pushing of the registration ID would be done client-side).
However, Google introduced a solution for this a few years ago: topics. It's possible to simply register each device to a 'global' topic (for example) and when you then want to send a message, you only have to specify the 'global' topic as the receiver. However, I can't find how this registration process is done for Chrome extensions. I've looked everywhere, but it seems like Chrome's GCM module doesn't support this yet. Am I correct in this and if so, is there an alternative way to pull this off?
Any help would be greatly appreciated!
If you call chrome.instanceID.getToken and then use the InstanceID API from your server to subscribe to a topic, it seems to work, but then the chrome extension doesn't get messages when you push to that topic, so I'm not sure if Google just needs to enable something on their side to make it work. But this is the closest I could get to it in any case.
firebaser here
Thanks for the great feedback. There is no way at the moment to subscribe to a topic from a browser. We're aware that having such an API would simplify the development model. We'd love to add this to Firebase, but as usual can't make any promises or commitments.
We have deployed the chrome service worker on our website in July 2015 and have over 380K active subscribers of which over 90% are mobile devices.
But we are encountering issues with the service worker. When a user's cache gets cleared or when many of the mobile apps like cleanmaster and other utility apps on a phone clear cache on a user's mobile. In that case we do not have any access to device token of that user. And hence even with 380K active users for which google sends us message ids we only get 50K impressions which is a very low ratio.
Our push notification subscription is implemented on a seperate subdomain as we could not make the entire site https then.
I have 2 queries:
We would love to know if Google is working on setting up a canonical system (Which is there in GCM for mobile apps) through which even if the user's cache gets cleared via these apps he might be able to get push notifications. Our users have complained again and again that even after subscription they are not receiving push that's when we went deeper and figured this out.
Also is there a way through which we can ensure we get back those users ?
When a user clears their cache in Chrome, it also unregisters service workers and clears the window cache as well. By unregistering the service workers it will unsubscribe the push subscriptions.
I agree that it's hard to understand the link between clearing a cache / cookies and how that relates to service worker and push notifications from the UI - the Chrome team are aware of this.
The best advice with respect to getting those users back is to ensure that when ever a user enables notifications and you get a subscription object, keep track of that decision as their last known decision and when the user re-visits your site, if they should be subscribed and you have permission, you can get a new subscription and send that back to your server.
Update
I put together this blog post: https://gauntface.com/blog/2016/05/01/push-debugging-analytics
Looking at your site there are a few issues in your code:
it seems that you have several broken promise chains and and overall it's hard to reason with what is going on in the push event, I'd strongly recommend tidying it up.
There is a minor but obvious bug when the service worker start ups and tries to examine the push subscription, which doesn't exist.
You are registering two service workers but only one of them gets used for push.
Checkout the blog post above, it covers how I came to that conclusion and some advice on how to fix it.
I'm in the middle of developing an application that integrates Box with an identity management environment for the purposes of SSO and user lifecycle management. Basically, our users use SAML to sign into their Box accounts, and then the status of their Box accounts is managed based on the status of their corporate accounts - if we terminate a user, the user's Box account needs to get disabled. This is one of many use cases that were in progress before the OAuth2 change.
Prior to the OAuth2 change, I was able to authenticate my enterprise admin account with the api_key and auth_token. This worked very well.
Now, with OAuth2, I'm not sure how to proceed. There is no UI for this at all, and I have no place to handle a redirect for the authorization token. Moreover, this is a nightly process that runs using the enterprise admin account, so I would have to get a new refresh token and bearer token every time this runs.
This doesn't make a lot of sense for my use case. Is there an alternative?
I am busy writing the same code with the same frustration as you have. However the refresh token does live for 14 days and what I plan to do is store the returned values encrypted in the registry. Each run my first action is to refresh the bearer key.
There however is no current timeline on the phasing out of the V1 Auth method and since some of the Enterprise stuff is yet to be ported to API V2 I suspect that if enough Enterprises push the BOX API team for a solution on this I am sure they will listen.
If I am honest I prefer the OAuth2 solution as it stops the key to your whole Enterprise data been sent in clear text across the internet as a URL param in API V1 and if someone did manage to break the SSL then only get a access token that is worth 60 mins max.
Not sure what language your writing the routines in but I am working with the API V2 SDK written by John Hoerr on GitHub and apart from a few little issues that he has fixed straight away from a .Net perspective it makes hitting the API a much more pleasant experience with all the de\serialisation handled by the SDK.