Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update notifications to use @{user_id} #1

Open
FletcherAU opened this issue Dec 9, 2024 · 3 comments
Open

Update notifications to use @{user_id} #1

FletcherAU opened this issue Dec 9, 2024 · 3 comments
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@FletcherAU
Copy link
Collaborator

No description provided.

@FletcherAU FletcherAU added enhancement New feature or request good first issue Good for newcomers labels Dec 9, 2024
@tazard
Copy link
Collaborator

tazard commented Jan 1, 2025

Not sure how to implement. Is there an example of how to perform this lookup? I can see using "event" rather than "body" as in this commit:

Perth-Artifactory/pledgeBot@18d9cf5#diff-0e11b91a8a0ba40a41c6dd98d1c60f67e2aee027fa70e9468d1fff522903ad8dR748

Not sure what can parse @(user_id} into user. I can see its use in an example that passes a string through ack() but we want to send this to logger.

ack(f"Hi, <@{user_id}>!")

@FletcherAU
Copy link
Collaborator Author

The primary issue here is that slack has deprecated usernames for some time. (Before our users started using the app). Instead of being prompted to set a username directly during onboarding it's now taken from the username specified in their email address. In most cases this works fine, but unfortunately so many of our members use dedicated addresses for each service it looks like we have a bunch of @artifactoryXXX usernames.

Admin 'artifactory045' has requested keys update

For text that's sent back into Slack (which is what this issue is referencing - Admin 'tazard' has requested keys update) there's no parsing needed, just send back the user_id formatted as in the example. This is present in Slack user objects as ['id'] instead of ['name']

For feeding it into a logger I'd use something simliar to the name mapping used in taiga_sync https://github.com/Perth-Artifactory/taiga_sync/blob/147a157d2117c71f7e6d1800c5f0f7732a502c7e/slack/misc.py#L153C1-L182C56

Note: The page on slack user objects kinda implies that all those fields (the display_name/real_name fields in particular) are there for all user objects. The id is always present but most of the others aren't included in the body of app action payloads. (which is why name_mapper hits the Slack api for the full user info.

@Swamp-Ig
Copy link

Swamp-Ig commented Jan 2, 2025

...In most cases this works fine, but unfortunately so many of our members use dedicated addresses for each service it looks like we have a bunch of @artifactoryXXX usernames.

🤣 surprisingly unsurprised, and a little proud! No other service I've come across has had this issue, and mostly I just get blank stares and requests for confirmation when I tell them my email address really is [email protected].

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

3 participants