In Microsoft Teams Channel the channel id has prefix "19:" what is the significance of this prefix and is it always going to be same?
The format of channel id is- "19:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX#thread.skype"
The "19:" it is just a type that defines the kind of object for Microsoft infrastructure internally (channel or team). There are other prefixes, like "28:xxxxx" for example for a bot, "29:xxxx" for a user, etc.
I would avoid relying on this prefix, though, and just use the whole ID as a string without trying to parse it.
Related
My calls to the API to get users work just fine, but the default URL does not return the home phone number, or the ip phone number.
/Users/jo.bloggs#example.com
adding parameters works for other things
/Users/jo.bloggs#example.com/?$select=id,displayName,mail,postalCode,businessPhones
works too, I have tried homephone, homephones, homePhone, homePhones and ipphone, ipphones, ipPhone, ipPhones but do not get those properties returned. We can see the properties filled in on our local Active Directory, so they are in there.
Looking at the docs I don't see mention of home or ip phones https://learn.microsoft.com/en-us/graph/api/resources/user?view=graph-rest-1.0 but I am hoping I am missing something.
To extend on my comment
For some reason the fieldname ipPhone does not work, only a prefixed
version with a 33 character hash in it extension_<33chars>_ipPhone. I
don't have direct access to the system, but have been told its been
done correctly, so it works enough for us
The URL path we have is now:
/Users/user.name#example.com/?$select=id,displayName,mail,homePhone,mobilePhone,businessPhones,ipPhone,profile,streetAddress,postalCode,extension_e48de7ec5b11c947e3006271ff83029_ipPhone,extension_e48de7ec5b11c947e3006271ff83029_homePhone
The codes for both of our fields fields are the same.
I presume the codes for other orgs will be different, but just in case I have not used our actual ones here.
Some attributes (such as ipPhone) that are synchronized by default might not be exposed using the Microsoft Graph API. In these cases, you can use the Azure AD Connect directory extension feature to synchronize the attribute to Azure AD.
I'm trying to send different message cards to multiple teams channels.
I have already created a webhook (telekom/webhook) for this which gives me the right variables via json.
There are four department receiver channels (telekom/rest-api-component) which are also configured to send pre-formatted teams message cards with the variables they have submitted.
Currently this happens to all channels at the same time. In between I would need an "action" in which I can decide which of the channels is served based on the input values. Unfortunately I don't find anything suitable due to the variety of the apis. Do you know how I could realize this ? So something like if value department = Backoffice then (Teams "Account Management") action.
In order to be able to talk with the different applications from Office 365 I wanted to use the Microsoft Graph api which is now available for some time. I couldn't find them in Flowground. Are you planning to include this module ?
For the implementation with Office365 flows this would be absolutely necessary for me.
I want to come back to this question: The CBR is a good choice for executing decisions indeed. But is is this the best solution in every situation? I do not think so.
Assume the following task:
Depending on an input parameter test you want to fire a request to different web services (WS1:google.de and WS2:bing.de)
Solution 1: You realize the requests with dedicated connectors for WS1 and WS2.
In this case you need the CBR in front of WS1 connector and WS2 connector to decide, what connector has to been used next.
Solution 2: You are able to realize both requests with REST-API connector. In this case you can use a JSONATA expression as URL mapping, e.g.
(test="google") ? "http://google.de" : http://bing.de
By using JSONATA expressions every connector has (limited) capability for executing decisions.
Solution 2 has a big advantage when you are using realtime flows. In this case you are able to reduce the number of connectors they are needed for running the flow and (very important from a cost perspective ) the number of permanently claimed token by this flow.
For reducing the complexity of JSONATA expressions (e.g. when you add further search engines) and for separation of individual configuration items you can use the configuration connector (we can discuss this in a separate thread if needed).
Solution 1 is the choice without alternative when you have to decide between different structures/connectors they need to be executed within a flow.
Please try the Content-Based-Router: https://doc.flowground.net/guides/content-based-router.html, it is available on the Connector Catalog.
I've been trying to return the employeeId of a user through the Microsoft Graph API but so far haven't had much luck.
I'm assuming this is probably because it doesn't exist in the metadata for the user in the Graph API so makes sense.
However, the property is populated in Azure AD. If I use the AZ command prompt to query the user I can see the property. Likewise, if I query the old Active Directory Graph API endpoint I can even see it there.
For example, querying
https://graph.windows.net/{tennant}/users/{upn}?api-version=1.6 directly I receive the employeeId as part of the response (using the ActiveDirectoryClient however seems to ignore this property and doesn't store it anywhere).
Is there any reason for this? Wouldn't it make sense to have it returned as an additional property? I've also looked into extensions, but as it's not an extension isn't returned there.
Any help would be appreciated. I can get the information I need by querying the old endpoint directly, but this seems like a complete backwards step and involves multiple queries to get the information I need - including having to use multiple end points (one of which I assume will be deprecated and removed soon).
EmployeeId is currently a beta feature and is only available in the beta endpoint of the Graph API.
So if you want to access the beta endpoint you just have to change the version to beta in your url. For example:
https://graph.microsoft.com/beta/me/
https://graph.microsoft.com/beta/users/{id|upn}/
https://graph.windows.net/{tennant}/users/{id|upn}?api-version=beta
For more information about the user-object in the beta endpoint see: https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/resources/user
I am planning to make a browser extension which uses Youtube data API v3. Since the code is public to the user, I am unable to use my API-key in the code. What is the correct way to use API in such a scenario? Also, since the API call will be made from user's browser, is there any other way to fetch data without using API-key at all?
TL;DR
On the API screen of Google Cloud Console, create a new key or edit an existing one to have no restriction. This will enable anyone to use this key to make requests the moment you publish it. There is no way to use the YouTube API without a key (or token respectively, when using OAuth). Your clients are allowed to consume up to 50.000.000 quota units per day, after which your app will essentially break for the rest of the day unless you buy more quota.
However, I have to disagree with the statement that you cannot (or "shouldn't") publish your API key; in certain scenarios, this may very well be desired.
Detailed Explanation
Web application keys used to be organized in two groups: Server keys and browser keys, the former of which where to be kept secret on the server of the web application, while the latter was sent to the client for use in JavaScript. Server keys could be configured to only be accepted from certain IP addresses. That way, even if someone got hold of your key, they wouldn't be able to use it. Browser keys could be restricted to a specified referrer, i.e. the domain (as in DNS) of your web application, so it wouldn't work on other sites beside your own either.
Nowadays, there is no distinction between server and browser keys anymore, they are simply called "API keys". This union makes perfect sense to me, since the only difference between the two types was how they were restricted. With the new API keys, one can still choose how to restrict its usage - or choose to not restrict the key at all.
This is where we get back to your case: It is, of course, possible to publish a key and at the same time not restrict it. Depending on how many users are using your app (and will be using it in the future) and how many are using your key for their own app (which you have no control over), the 50 million quota limit will work out for you or it will not.
An then there's responsibility as well. You are responsible for the queries that are made with your API key. This is probably one of the reasons why YouTube doesn't allow for requests without a valid key: They need to stay in control of their service and, naturally, want to protect it from DOS attacks. If someone does mischief with your key, you are the one who gets punished for it, usually by deactivation of the key.
Much like the "mailto" URL prefix launches the user's default mail program and starts a new email with specified address, is there a similar URL scheme that would initiate a phone call? Perhaps "phone," "call," or "sip"?
Incidentally, I'm targeting a platform that is using Cisco CUPS, so there may be a platform-specific way for me to initiate a call that is particular to Cisco, but I thought I'd ask the more general question first. However if anyone knows specifically how to programmatically initiate a call via CUPS, that would be great too.
The official standard for providing a telephone number as a URI is here: http://www.ietf.org/rfc/rfc3966.txt
It basically says use tel: as the prefix, and start the number with +[international dialling code] before the number itself. You can put non-numeric characters as separators (e.g. -) but they must be ignored. So a London (UK) number might be:
tel:+44-20-8123-4567
A New York (US) number:
tel:+1-212-555-1234
There is such a URI scheme: tel. It has an elaborate syntax, but here is a simple example of its usage:
tel:123-4567
For the full specification, refer to http://www.ietf.org/rfc/rfc3966.txt .
I'm after the same sort of functionality for Microsoft Office Communicator. After a bit of investigation I found that the following URI syntax will initiate a (VoIP) phone call via communicator:
tel:+number
eg: to get communicator to call my extension:
tel:+7780
sip: (or sips:) is the official URI scheme for SIP, and I think callto: was used by Skype, but is deprecated.