Closed yashgandhi-32 closed 1 year ago
@yashgandhi-32 thanks for writing in 💯
This is a good question, from what I know, when accessing a user.team_id
the contents should relate to the team the user belongs to, if this user belongs to an org
the team_id
should relate to the org
When accessing the team_id
from the payload of a slash command
the team_id
will simply relate to the direct workspace the command was executed in
let me know if this answers your issue
@WilliamBergamin
My user is part of all three workspace , why it giving same team_id in all workspace that hard to get. I am not able to find any clear docs how to setup my app for enterprise grid. I want to understand here what is right approach of handling enterprise grid cases and their data will be considered same or not. Like in multiple workspaces users will have same view of dm / activity and all ?
Users in enterprise orgs
are slightly different from ones that are only in a single workspace, the changes are documented here
I am not able to find any clear docs how to setup my app for enterprise grid
For context on org-wide/enterprise-grid apps there is Building apps in Enterprise Grid, Org-wide app overview & Preparing for org-wide app deployment
Let me know if this gives you the context you are looking for
@yashgandhi-32 As @WilliamBergamin mentioned earlier, DMs and Home tabs in an Enterprise Grid organization behave slightly differently compared to those in a single workspace environment.
DMs and Home tabs are accessible from any workspace within an Enterprise Grid organization. Therefore, Events API payloads from a DM or Home tab may not always include the workspace's ID (team_id) where the user is located at the time of the event. However, you can expect user interactions (such as slash commands, shortcuts) within a specific workspace or channel to provide the workspace's ID.
I hope this information also proves helpful.
Thanks for ur answer @WilliamBergamin and @seratch . I also checked doc , pls help me understand below questions to clarify more
.users.info
details using workspace A token for a user that is part of workspace B. Is it correct way ? or any limitations here@yashgandhi-32
In enterprise grid its good to identify user using enterprise id + userid unlike teamed + userid .
Yes, your understanding is correct. When your app works only for a single workspace in a Grid, either is fine though.
Also for token as I am not supporting enterprise install for now but I saw I am able to get .users.info details using workspace A token for a user that is part of workspace B. Is it correct way ? or any limitations here
This is not always true. If a user has not yet joined workspace A while the same user is in workspace B, your users.info API call for the user with a bot token, which is associated with workspace A, may fail. However, if the user is a member of a public Slack Connect channel between workspace A and B, you may be able to receive limited information in response to users.info API call (even when the user is not a member of workspace A).
Is everything clear now? (if yes, would you mind closing this issue?)
@seratch one cross question
This is not always true. If a user has not yet joined workspace A while the same user is in workspace B, your users.info API call for the user with a bot token, which is associated with workspace A, may fail
For this case what is right approach , if I am able to dm a user of workspace B from workspace A , how should I fetch info corresponding to that user from workspace A as my bot only available in A as you mentioned it may fail?
if I am able to dm a user of workspace B from workspace A
No, it's not possible. In the case, your app is unable to send a DM to the user because the app does not have any authority for workspace B only data including its users. As long as your app is not org-wide installed, your app still does not have access to all the users in the entire Enterprise Grid org. Does this make sense to you?
As I said earlier, please note that, when the workspace B user is a member of a Slack Connect channel with workspace A, your app may be able to fech the user's info and send messages to the user. Otherwise, the situation I described in my previous comment can arise.
Thanks @seratch , I will look more in case of further info I will check again
@seratch I just tested for info retrieval , I am not sure about DM, but user info I got
I triggered this command from workspace A /getinfo @auserfromworkspaceB
and I was able to retrieve information on the backend using workspace A token, this app is not org wide install . So can it be assumed it will work always ?
It depends on what workspace you're in. In your case, the workspace A may have full access to all users. If that's the case, you may not worry about it for your use case.
full access to all users
If I am able to tag a user in slash command , can it be presumed I have access to that particular user from that workspace? for me I am storing some Information about a user and I want to display info for a user coming in slash command like/info @user
If I am able to tag a user in slash command , can it be presumed I have access to that particular user from that workspace?
Yes, this is correct.
One thing to note is that the argument string of a slash command invocation does not provide included users' IDs. The whole argument is just a plain string without any special syntax (yes, this is a big downside of slash commnd but there is no plan to change this). So, if there are several users with the same display name in the workspace/org, you may not be able to identify who is mentioned. For this reason, I'd recommend opening a modal view to collect user inputs rather than simple slash command usage. You can open a modal using views.open API in response to slash command / shortcut invocation requests.
Thanks @seratch now its clear
For what you said there is a way available to convert username into userId in slash command by enabling below option ?
Oops, I am sorry. I totally forgot about the option 🤦 You're right!
@seratch All fine you already remember so much hahah .
I also forgot about this option! thanks for mentioning it @yashgandhi-32
i have a enterprise org with three workspace A B C I have a primary owner available in all three workspace. Now when i am clicking action button from home tab in any of three workspace and log user.id , i always receive team id of C workspace?
I have also a user available in two workspace on slash command it giving me right team id using
body.team_id
but on action click when I try to getuser.team_id
it give me only one workspace userid everywhere?I did not understand this behaviour why its not consistent ?