The MS Graph API has the possibility to list the direct members of an AD group using
/groups/{id}/members
Is there a way to get both direct and indirect members, i.e. member of members of members and so on and so forth.
I would like to avoid the need to implement some recursive logic on the client if it can be done another way, possibly through the use of OData query parameters?
I have tried the following using $expand and $level, but unfortunately the 'members' navigation property doesn't exist on the child groups for some reason and I guess that's why they are not expanded.
https://graph.microsoft.com/v1.0/groups('{group-id}')?$expand=members($levels=max)
Unrelated to the question, could someone with the necessary SO permissions please make the ms-graph and the microsoftgraph tags synonyms?
Update: The feature request mentioned below is in beta now.
I found a feature request on uservoice.com for this, so it seems like it does not exist yet. If you came here looking for the solution, I encourage you to go and vote for the feature.
Related
I'm using tdlib and currently trying to create another user's profile screen like this one:
There is usually a field on this screen called "Notifications" containing information on whether or not notifications for given user are muted and if so then for how long. All other fields seem easy to retrieve, but this one is a head-scratcher for me.
All other field are stored in User entity, but what am I supposed to do with this one? Call createPrivateChat only to get one field (namely notificationSettings)? This seems like overkill to me. Isn't there easiest ways to get this? In this issue sapelkinAV states that "chatID is equals UserId". Is it correct? Even if so it might just be an internal thing that we shouldn't rely on, and I can't find neither proofs nor restrictions on abusing this "feature".
If it is fine, than I could use getNotificationSettings and pass notificationSettingsScopeChat as scope parameter. Would it be the right solution? Any thoughts and advices are appreciated!
Official answer (obtained from TDLib bot):
Your usage of createPrivateChat is absolutely correct. To get correct NotificationSettings you need to get information about the corresponding chat.
So I ended up doing exactly that.
Call createPrivateChat only to get one field (namely notificationSettings)?
recently i thought to apply roles to users in a different way,without using role manager etc.like create one column named 'ROLES'...and redirect user by checking this column at login time.I know so many of you are thinking what is i am gonna do.I am also thinking the same.I know one drawback of this technique,that is one user cant have multiple roles.Is there any other drawbacks of this technique and why should this technique be avoided and one should use role manager instead of this?
Well Rohan, There is nothing wrong with your way. I have used this type of techniques for 2 years because I was too lazy to go thru the role managers and overriding it where needed.
However i feel now that I have always reinvented the wheel. Its your persective how you see that.
and your last question "why should this technique be avoided and one should use role manager instead of this?" the answer is because it is readymade and timetested. Any new code that you write has a theoritical limit that it can have bug, so suppose you have rolled out your own authentication engine- you will have to test it.. Isnt it extra efford that you have to put?
Use that Link, I think it will help you..
We have a requirement to allow customising our core product and adding additional fields on a per client basis e.g. People entity some client wants to record their favourite colour etc. As far as I know we can't add properties to EF at runtime as it needs classes defined at startup. Each customer has their own database but we are deploying the same solution to all customers with all additional code. We are then detecting which customer they are and running customer specific services etc.
Now the last thing I want is to be forking my project or alternatively adding all fields for all clients. This would seem likely to become a nightmare. Also more often than not the extra fields would only be required in a very limited amount of place. Maybe some reports, couple of screens etc.
I found this article from Jermey Miller http://codebetter.com/jeremymiller/2010/02/16/our-extension-properties-story/ describing how they are adding extension properties and having them go from domain to the web front end.
Has anyone else implemented anything similar using EF? How did it work out? Are there any blogs/samples that anyone has seen? I am not sure if I am searching for the right thing even if someone could tell me the generic name for what we want to do that would help. I'm guessing it is a problem that comes up for other people.
Linked question still requires some forking or implementing all possible extensions in single solution because you are still creating strongly typed extensions upfront (= you know upfront what extensions customer wants). It is not generally extensible solution. If you want generic extensible solution you must leave strongly typed world and describe extensions as data.
You will need to use some metamodel. Your entity classes will contain only properties used by all customers and navigation property to special extension entity (additional table per every extensible entity) where you will be able to put additional properties as name / value pair (you can add other columns like type, validation, etc. if needed).
This will in general moves part of your model from hardcoded scenario to configuration based scenario and your customers will even be allowed to define extensions at runtime (if you implement such feature).
What rule of thumb do you use for deciding to use node_load() or just writing a direct db_query()?
In a situation I'm looking at right now I need to get some node data and resolve data on two nodereference fields. So that would be 3 calls to node_load(). At some point here, would it be more efficient to construct the query with Joins directly?
This is for use in a self contained module that won't be distributed or used anywhere else, so I don't believe I need to worry about subverting node modification hooks (or do I?).
Edit:
Thinking about my question more, node_load() is only really applicable when you have one node to grab (and then maybe drilling down further into nodereferences like in my example). But as soon as you need to return more than one node based on some criteria, you're pretty much forced to use db_query right? Does Drupal have any abstracted API for writing queries like this?
Not a full answer (Not sure myself), just some hints.
node_load() is using a static cache (in Drupal 7, you can even use the entity_cache module to make it a permanent cache). If the nodes you are loading are being used a second time on the same page, that call will be free.
Querying CCK-tables is tricky. The schema structure can change completely based on configuration, for example when using a single or multiple values.
The reasoning behind using API methods for DB calls over direct DB calls is to provide a DB abstraction layer so that your app could move between supported database engines etc, also it enables your app to gracefully handle any schema changes (however unlikely) that core/module may make to the tables in question. It's also likely easier as #Berdir says for CCK fields and Node_Ref fields, but that depends on which you are more confident with Drupal API& PHP or MySQL...the payoff of doing it the Drupal way is increased future productivity and understanding of the codebase and what is possible :)
Oh and my rule of thumb is - Do it the Drupal way if at all possible (possible being variable depending on app time/cost/performance/whatever requirements)
Background: I have a complex search form that stores the query and it's hash in a cache. Once the cache is set, I redirect to something like /searchresults/e6c86fadc7e4b7a2d068932efc9cc358 where that big long string on the end is the md5 hash of my query. I need to make a new argument for views to know what the hash is good for.
The reason for all this hastle is because my original search form is way to complex and has way to many arguments to consider putting them all into the path and expecting to do the filtering with the normal views arguments.
Now for my question. I have been reading views 2 documentation but not figuring out how to accomplish this custom argument. It doesn't seem to me like this should be as hard as it seems to me like it must be. Leaving aside any knowledge of the veiws api, it would seem that all I need is a callback function that will take the argument from the path as it's only argument and return a list of node id's to filter to.
Can anyone point me to a solution or give me some example code?
Thanks for your help! You guys are great.
PS. I am pretty sure that my design is the best I can come up with, lets don't get off my question and into cross checking my design logic if we can help it.
It's not as easy as you would like to make it.
In views, arguments are used to return objects, fx user, node, term, custom object. So you could make some custom code, to get the "query object". That would only be first step. You then need to get the info from the query object. You could either try making a custom relationship bond with the nodes or build your own filter to make the SQL needed. This can quickly become a confusing time sink.
Instead, I would suggest that you use hook_views_query_alter, which will allow you to alter the query. Since you already have the SQL, it's just a matter of checking for the hash, and if it's there, alter the query. Should be a pretty simple thing to do. Only thing that is a bit tricky, is that you have to make the query with the query object that views uses, but it's not that hard to figure out.