I create a group in graph with the following body:
{
"description": "<GroupDescription>",
"displayName": "<GroupTitle>",
"groupTypes": [
"Unified"
],
"mailEnabled": true,
"mailNickname": "<SiteName>",
"owners#odata.bind": [
"https://graph.microsoft.com/v1.0/users/<userID>",
"https://graph.microsoft.com/v1.0/users/<userID>"
],
"securityEnabled": false,
"visibility": "private"
}
None of the owners added with the code:
"owners#odata.bind": [
"https://graph.microsoft.com/v1.0/users/<userID>",
"https://graph.microsoft.com/v1.0/users/<userID>"
]
receive an email. Users added to the group later will receive one. Is there a way to make the owners receive a welcome-email when added during the group creation?
The Unified Group Welcome Message is only sent to new members. If you would like to notify them that they've been added to a Group, you can add them to both owners and members.
This is also the guidance for Teams:
We recommend that when you add an owner, you also add that user as a member. If a team has an owner who is not also a member, ownership and membership changes might not show up immediately in Microsoft Teams. In addition, different apps and APIs will handle that differently. For example, Microsoft Teams will show teams that the user is either a member or an owner of, while the Microsoft Teams PowerShell cmdlets and the /me/joinedTeams API will only show teams the user is a member of. To avoid confusion, add all owners to the members list as well.
Related
I am trying to add a subscription for custom objects in commerce tool. I am using the following definition:
{
"destination": {
"type": "AzureServiceBus",
"connectionString": "**********************"
},
"messages": [
{
"resourceTypeId": "key-value-document",
"types": []
}
],
"key": "customeobj"
}
But I am getting this error:
The resource type ID 'key-value-document' is unknown or not supported by messages subscriptions. These resource type IDs are supported: review, cart, payment, order, customer, category, inventory-entry, product, customer-group, store, product-type, product-selection.
It would be great if someone knows what to do about this.
As the error suggests, message subscriptions are only supported for messages on order, product, category, payment, customer, review, inventory entry and store at the moment.
Change subscriptions support the resource type key-value-document if that is sufficient for your use case.
They provide the example below in the Firebase documentation for data organization.
What happens when there are eventually 10,000 users signed up, but I decide to add another group? You'd have to write something to add the group with every existing user attached to that group as well as add every existing user to the new group entry? Is that right?
// An index to track Ada's memberships
{
"users": {
"alovelace": {
"name": "Ada Lovelace",
// Index Ada's groups in her profile
"groups": {
// the value here doesn't matter, just that the key exists
"techpioneers": true,
"womentechmakers": true
}
},
...
},
"groups": {
"techpioneers": {
"name": "Historical Tech Pioneers",
"members": {
"alovelace": true,
"ghopper": true,
"eclarke": true
}
},
...
I'm building a little game with React-Native and using Realtime Database in Firebase for my database. I am building a customize section, where a user can purchase to unlock more customizations. If they purchase an item, it will set effect/{purchasedId}/members/{uid}/({isPurchased:true}) which will then display in my CustomizedSection with getCustomizablesForUserByUserId.
If I want to add more effects down the line, will I just have to add a new effect and attach every members ID to it?
Thanks!
What happens when there are eventually 10,000 users signed up, but I decide to add another group? You'd have to write something to add the group with every existing user attached to that group as well as add every existing user to the new group entry? Is that right?
That is indeed correct. This process is known as backfilling, and is a normal (and sometimes quite large) concern when using schemaless NoSQL databases.
My id token has group (as role) ids only
"roles": [
"729b24b5-c527-440e-9ef6-81a04415e7ba",
"8d4f9343-10c3-43a2-9efe-34cfd740d020",
"81715416-9be4-43d7-807a-d5ccc9420cf7",
"1b5e6d7b-0ee0-4212-a5b9-cd5c3ca07a4a"
],
Even set to sAMAccountName
Any idea to return the group names instead?
If you are expecting group names in the claims of ID/Access/SAML token, unfortunately currently that is not supported due to some limitations. You would only have the object ids (guid) of the groups in the claim for AAD managed groups.
If you absolutely need group names for your purpose, consider a separate Graph API call to list group memberships of a user.
Also feel free to upvote on the feature request of group names in claims here.
Please refer to this similar question
I know this question is rather old already, but I experienced the same issue in summer 2021 still when trying to create a new .NET API project. Probably people stumbling across it in 2021 could make use of my solution:
I decided to create a NuGet package that resolves the group names using Microsoft Graph for applications using .NETs Microsoft.Identity.Web package (mostly ASP.NET Core applications).
Feel free to take a look into https://github.com/peterwurzinger/AuthOida if that's applicable to your use case.
This is relatively old, but there's answer to that.
You can translate your groups to names by adjusting your application manifest.
Go to your application manifest via Applications and SSO options, you should see there "Manifest option" it should return a JSON which you can modify.
The important bit is in the optionalClaims, you need to add to your groups.additionalProperties section cloud_displayname option like this:
...
"optionalClaims": {
"idToken": [
{
"name": "preferred_username",
"source": null,
"essential": false,
"additionalProperties": []
},
{
"name": "groups",
"source": null,
"essential": false,
"additionalProperties": [
"sam_account_name",
"emit_as_roles",
"cloud_displayname"
]
}
],
...
In Watson conversation. I have an entity Fruit
Fruit values:
-Apple
-Orange
-Banana
-Kiwi
I'd like to create a new dialog where the intent of the user is to get a list of all the values of a specific entity, in this case a list of all the fruits, . So the conversation should go:
User: "What fruits do you have?"
And then I'd like Watson to respond
Watson: "The fruits we got in store are: Apple, Orange, Banana, Kiwi"
All the stuff I found is of recognizing an entity in users input, such as
User: "Do you have apples?"
And Watson picking up Apples
Just to clarify, setting an array with the possible options declarativly on a context variable as shown below is no good for me, I need to get them dynamically from the entity
{
"context": {
"fruits": [
"lemon",
"orange",
"apple"
]
},
"output": {
"text": {
"values": [
"This is the array: <? $fruits.join(', ') ?>"
],
"selection_policy": "sequential"
}
}
}
Thankss!
AFAIK it is not possible to directly access the workspace metadata from within a dialog. You have access to what was detected using the intents, entities and context variables. However, I see two options you have:
Use your application program that drives the chat to access the entity definitions on the fly, then create a context variable in which you offer the entity choices. The API to list entities can be used from any programming language and there are SDKs.
With a relatively new feature you can invoke server or client actions from within a dialog node, i.e., make programmatic calls. Use that and the API mentioned above to obtain the list of entity values.
.
I want to have the users in the database structured in a way that makes it easier for a human to read and manage. Using the users email address as the property name instead of the User ID:
Users:
"Users" : {
"emailaddress#domain.com":{
"id": "DK66qu2dfUHt4ASfy36sdfYHS9fh",
"name": "A Display Name",
"groups": {
"moderators": true,
"users": true
}
},
{...}
}
So that if I have a list of users in a group, they can be read as a list of emails and not a list of user IDs.
Groups Such as:
"Groups": {
"moderators":{
"name": "moderator",
"members": {
"emailaddress#domain.com": true,
"emailaddress2#domain.com": true
}
}
}
Groups Instead of:
"Groups": {
"moderators":{
"name": "moderator",
"members": {
"DK66qu2dfUHt4ASfy36sdfYHS9fh": true,
"K2fkHYQDFOge3Hw7SjRaGP3N2sdo": true
}
}
}
However, using rules to verify a property of the user (such as their group), would require me to maintain two list of users, one like the list above, and another essentially a table of key-value pairs of ID's and email addresses so I can get the users email address from their uid.
Pseudo-code rule: Users[UsersKeyVal[auth.uid]].groups.moderator == true
With firebase, what would be considered the most acceptable practice? What are the pros and cons of both?
Please do not store user data under their email address! This will be BIG TROUBLE later.
Your users node should follow the 'standard' Firebase design pattern
users
uid_0
name:
gender:
etc
uid_1
name:
gender:
etc
The bottom line is that in general, it's best to disassociate the dynamic data stored in the node from the key of the node.
Why?
Suppose you build a complex structure with all kinds of links and references to frank#mycoolcompany.com and then #mycoolcompany.com gets acquired by #mynotsocoolcompany.com. Well, you will then have to go in and rebuild every reference to franks's email in the entire database. ugh.
Then what if there are 100 or 1000 users #mycoolcompany.com! Ouch.
If you disassociate the data, like my per above suggested structure, you just change the email address within the node and everything else... just works!
PLEASE, read this answer on stack overflow - written by a Firebaser and addresses your question
Firebase data structure and url
In my opinion there is no problem with your data structure.
According to the Doc
This is a necessary redundancy for two-way relationships. It allows you to quickly and efficiently fetch your members memberships
Also using the generated UId from firebase or your custom Id (here your e-mail) doesn't change the way firebase works. You just have to make sure your e-mail are unique.