I have setup the Outlook login plugin, and it works fine, however on the permissions page it seems to be requesting more permissions than I have selected in the Microsoft application settings. I only need the user’s name and email address, but it is requesting access to mail and contacts.
Wondered if anyone has experience or knowledge on setting up these permissions.
Hi @jack, that’s one of Coaching Bubble’s plugins. It’s asking for all those permissions because the plugin has a suite of actions that require them. It’s sort of an all or none deal with the way it’s set up.
If you’re interested in a custom, more limited integration so that it only asks for the permissions you need, reach out and I’d be happy to work with you.
@romanmg is it possible to pull more then the first 10 records from the data? i cant figure out how to get the rest of the list data beyond that point?
The response will probably be using pagination. So will provide you with x amount of data and then a “nextlink” to page 2.
This can be an issue with bubble, in that you need to ensure the “initialise” call has pagination.
Whilst I am broadly in favour of Plugins (and gaby’s are always excellent) if you are looking to make a lot of use of something as complex as the MS Graph API, I would urge you to spend some time understanding the way the API works natively.
@ryan8, I’ve just added pagination parameters to the List Events, Contacts, Messages, Calendars, and Folders data calls. Use “skip” to skip the first X number of results. Use “top” to request X number of results in a page. The response will contain a parameter for @odata:nextLink whose value is a URL with a skip parameter you can use to retrieve the next page of results. E.g. https://graph.microsoft.com/v1.0/me/calendar/events?$skip=20
@NigelG is exactly right. This is a pagination system so that you can 1) specify how many results to return in a page and 2) specify which page to go to via an index number. Different APIs handle pagination more or less the same… some will let you say “give me page 2 of 10” while others say “start the results list at item 30 and return 20 items from there” or some combination. This particular API we’re talking about does the latter, hence the “skip” labeling - you’re “skipping” X number of results.
When you retrieve a list, one of the fields that comes back is @odata:nextLink. The value of that field is a full URL. That url has the parameter “skip.” You want to extract the value of that parameter (a number) to put it back into the skip input of the plugin to get the next set of results.
So, you’ll need to design the logic so that it can all be done dynamically, meaning you’re able to retrieve and insert the next skip number as long as there is a skip number to insert. Some of that design will also depend on your specific set up.
None of these values have anything to do with your app’s url. They’re coming back as part of the API response, and you can use those values to retrieve more data via the plugin all over again. Hope that makes sense.
If you want to get it set up together for your app specifically, you’re welcome to book a coaching session, and we can do it live.
Until you get a deltaLink. Then you need to make a decision on continually running a workflow to check to see if the deltaLink has new values or go the route of setting up Subscriptions, which will require using something like Webtask.io or AWS Lambda for part of the processing due to the way Microsoft wants the response to look (i.e. send me a 202 response instead of 200 – 200 is the default that Bubble uses and there isn’t a way to change it, so you have to intercept the response with another tool and update it before sending).
As I’ve mentioned elsewhere, it would be nice (it is essential, actually) if we could explicitly set the response type in API workflows. This is a blocking thing that’s keeping me from implementing oEmbed, for example (the rules of which specify various types of 40x responses to indicate a pretty wide array of conditions). Yours is another great example of how this missing feature forces us to go outside of Bubble to do some things that would otherwise be super easy in Bubble.
In fact, if we had that (and also could have GET calls trigger our own custom API workflows in addition to the “built in” get/data features), Bubble could be used to build API Gateways in a super easy and fast way.
I am trying to figure out how to prefilter the emails down by an email address… the problem i run into is the only way i can figure out how to do this is the generate a list of numbers that counts the emails pulled, then do an API workflow on that number list, calling each email by using that number as the skip and setting it to full :first-item
This pulls all the emails into the database. Then i have to run another action to go through and delete ike 80% of them that dont match.
Is there some easy way to prefilter the emails? This is so much data processing the way im doing it so i think my lack of experience here is possibly causing me to go about this wrong.