I'm trying to grab only properties "id" and "userPrincipalName" from the teacher when getting educationClasses with $expand=teacher as parameter. But whatever I do, I keep getting the full teacher/user object.
https://graph.microsoft.com/v1.0/education/classes?$expand=teachers($select=id,userPrincipalName)
But it gives the same result as this one:
https://graph.microsoft.com/v1.0/education/classes?$expand=teachers
What am I doing wrong?
Or is this one of the endpoints where the expand+select feature is not fully supported? I don't want the full teacher object because it contains assignedLicenses, assignedPlans, provisionedPlans and a whole lot of stuff I will never need in this request.
And...it's production, so I'd like to avoid using the BETA endpoint if possible.
Yep, looks like the underlying AAD storage doesn't support expand plus select.
You can see what is happening under the covers by appending the &$whatif to your query.
Not a lot we can do about this, as the AAD team aren't investing in adding richness here right now.
Related
In Azure portal on a managed device detail page it shows two types of users,
The "Primary" user and the "Enrolled by" user. I'm trying to figure out how I can retrieve the latter
using the Microsoft Graph API. What I've tried so far is pretty much every managed device related API.
The ones I mainly use are the https://learn.microsoft.com/en-us/graph/api/intune-devices-manageddevice-list?view=graph-rest-1.0 and https://learn.microsoft.com/en-us/graph/api/intune-devices-manageddevice-get?view=graph-rest-1
I've also looked at pretty much all the beta variants of the related API documentation if and when they are available. My problem is that it seems like there is no way to retrieve this information.
You have to query the related object of the managed device
https://graph.microsoft.com/beta/devicemanagement/manageddevices/b32d84d4-50da-469f-a65d-2f1c30f8da67/users
Also you will get object id of the primary owner.
https://www.youtube.com/watch?v=CTEs_lHtZJ4&list=PL8wOlV8Hv3o9TUJxUR9T78TevVjtsRAup&ab_channel=ConceptsWork
https://www.youtube.com/watch?v=yw5Cz5rO6_Y&list=PL8wOlV8Hv3o_KgAx8JmnqM4G97U0vPR9l&ab_channel=ConceptsWork
We have an OData v4 API that we are putting behind an Azure API Management (AAM) service, but have run into a problem configuring the routes/oerations. In a nutshell, the issue is that AAM will reject a query for a route/operation unless it is explicitly configured (you get a 404 error), but with OData there can be a route for every attribute (property) of every operation (endpoint). The problem quickly becomes unmanageable.
OData allows you to query an individual attribute/property (eg GET ~/api/Person(1234)/FirstName. If we put this behind AAM, we need to define it as an operation. That's OK as long as there are only a few of these, but it potentially means you quickly have to define hundreds/thousands of operations (unless I've missed something). We have an API with about 35 top level operations. Each resource has 20 attributes on average. That's 700 operations we would need to define. Apart from the work involved, that would be a shocking experience for users of the AAM developer portal.
I'm hoping someone can tell me an easy way to get around this problem. I know I can script the creation of these. You an also get around this problem to some degree if you use an OData $select query parameter (which is what I've suggested in the meantime). I can't get over the feeling I've missed something here. Is there a way of defining some sort of wildcard portion to the operation (eg /Person/*)? I can't find anything like that in the AAM documentation.
Try using URL templates instead of writing them explicitly, i.e. define operations for /{entity}/{property} this way it'll match every entity and every property of every entity. And you could use wildcards as well if you want to capture multiple segments at the end of URL.
I just started a github project for Identityserver4 with a neo4j backing store.
(https://github.com/AndreSteenbergen/IdentityServer4.Contrib.Neo4jBolt) I am asking myself if I should make the relation (HAS_Scope) to the Resources directly, or if I should keep the nodes as they are now. I am very tempted to use HAS_Scope to the resources.
What are your ideas? Make a direct link, or just keep it as is?
I just debugged some more: when making an extra client with unknown scope, an error is given using that particular client. I think it is better to make sure the data is consistent in the first place.
Here is the second attempt, storing identityserver configuration in Neo4j. I have updated the github project accordingly. It works as a charm right now.
For the careful reader, I know it is not wise to use 1 secret for more then one client. A graph database can point out these strange things at once ....
I havent found any mention in Orchard documentation about IdentityPart despite it being used in some main modules like Comments. I took a look at some relevant sources, but it didn't help me to fully understand it's purpose.
So what's it for and when should I use it?
Thanks in advance!
This is part of the import/export feature. In order to be able to move contents around servers reliably and in a repeatable way that takes into account updated and new items, we need a way to identify content items that's not just a simple id. Some contents have a path but not all types do (widgets, users, etc.). The export/import hooks for any part can participate in building the id of the item and in recognizing it on import. The routable part for example implements the use of path. But for those types that do not have routable, you can add the IdentityPart to fulfill that role. The id that gets exported in the end is a composite of all contributed ids.
Makes sense?
Well, my question is simple.
Does the ID affect the position of a webpage on Google ?
I have links like this
http://example.com/news/title-slug/15/
and people say to me that I should remove the ID from the URL.
And I belive that is not true. By my logic, you can't depend on the title's slug. I know it should work perfectly fine if there aren't two pages that have the same title, but why should I remove the ID if there is no harm when it's there.
Yes, leave it there.
Google has no business trying to second-guess what each element of a URL represents and changing its index based on that.
URLs by their nature can map to any resource, and I'm pretty sure Google recognises that. All you should do is ensure that multiple URLs don't have the same content by using redirects. So, for example, http://example.com/news/wrong-title-slug/15/ should redirect back to http://example.com/news/title-slug/15/ rather than just echo back the same page. Google doesn't really like duplicate content.
It's fine.
But I would not put that behind the title-slug though. Some url might get more confusing than the others.
http://example.com/entry/how-to-solve-question-45/15
a better one would be :
http://example.com/entry/15/how-to-solve-question-45
Besides, you can't really rely on just the title-slug, because changing the title of an entry means breaking user's bookmark. Not to mention that it is faster to retrieve an entry from the database by an integer ID instead of an url-slug.
The problem here is not whether Google will accept it, but whether or not doing so is user-friendly.
A common reason for keeping the ID in a URL is to ensure that the URL is unique. For example, if two people on here were to create a question named "Jon Skeet Facts" we'd have a problem, whereas with the ID the users are aware that they are two different questions with the same title. This is the same as with relational databases where a unique identifier is required.
In essence, why care what Google thinks? The whole Search Engine Optimisation industry is a farce, and this is coming from someone who has been paid more than once as a SEO Consultant. Why follow what Google wants when you can map Google's intentions by making your website perfect for the user? If you make a good website Google will reward you. The ID has a reason to be there, so keep it in.
I think your fine leaving it in. Seems to make sense as you get the element for identification and the element for being descriptive. It is done on here after all.
Zeus won't strike you down for it. I prefer not to have meaningless numbers in there because it's not very attractive or semantic.
Having the id will NOT hurt your SEO rankings. Having the slug there ensures that the page's main keywords will be indexed so it's all good.