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

Adding support for new user-change events with types #1448

Merged
merged 3 commits into from
May 13, 2022

Conversation

filmaj
Copy link
Contributor

@filmaj filmaj commented May 10, 2022

These are UserHuddleChangedEvent, UserProfileChangedEvent, UserStatusChangedEvent.

I assume this is a minor version bump but maybe not? Not sure if a new type counts as an API addition? 🤔

…edEvent, UserProfileChangedEvent, UserStatusChangedEvent).
@filmaj filmaj added enhancement M-T: A feature request for new functionality semver:minor labels May 10, 2022
@filmaj filmaj added this to the 3.12.0 milestone May 10, 2022
@filmaj filmaj requested review from seratch and srajiang May 10, 2022 16:14
@filmaj filmaj self-assigned this May 10, 2022
@codecov
Copy link

codecov bot commented May 10, 2022

Codecov Report

Merging #1448 (832850a) into main (0c996d0) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #1448   +/-   ##
=======================================
  Coverage   81.97%   81.97%           
=======================================
  Files          18       18           
  Lines        1476     1476           
  Branches      434      434           
=======================================
  Hits         1210     1210           
  Misses        172      172           
  Partials       94       94           

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0c996d0...832850a. Read the comment docs.

Copy link
Member

@mwbrooks mwbrooks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, but I'll let @srajiang and @seratch have a final approval.

@@ -937,6 +940,240 @@ export interface UserChangeEvent {
cache_ts: number;
}

export interface UserHuddleChangedEvent {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@filmaj for my own reference, what source did you use for the schema reference? api.slack.com, Java/Python, or something else?

Copy link
Contributor Author

@filmaj filmaj May 10, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

api.slack.com, I checked the public-facing docs (i.e. https://api.slack.com/events/user_huddle_changed), and all three event descriptions say:

The event is identical to the existing user_change event. Both user_change and user_huddle_changed are dispatched. at the exact same time.

... so I just copy/pasted the existing user_change event.

Sort of awkward that the verb tense goes from present tense (user_change) to past tense (user_huddle_changed)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a lot to be desired with respect to the accuracy / completeness of the api site and I don't know how to make it better. We don't seem to even have a good public facing SOT for user_change to base off of since the example is incomplete so, "everything is identical to user_change" feels unhelpful to me personally.

@mwbrooks
Copy link
Member

I assume this is a minor version bump but maybe not? Not sure if a new type counts as an API addition? 🤔

I'd also consider this a .minor because we're adding support for the event types - a feature that didn't exist previously. But I'm also curious how we've versioned these changes in the past!

@filmaj
Copy link
Contributor Author

filmaj commented May 10, 2022

But I'm also curious how we've versioned these changes in the past!

I looked to @srajiang's past PR as a guide before I tackled this: #1008 - it looks like that was a minor bump back then.

Copy link
Member

@srajiang srajiang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👋 Did a first pass! I wonder whether we don't get more feedback on the accuracy of these types from the community because people don't use them. Yes this one should probably be a minor.

two_factor_type: string;
has_files: boolean;
is_workflow_bot: boolean;
who_can_share_contact_card: boolean;
Copy link
Member

@srajiang srajiang May 10, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this is at least type string if not constrained further given"EVERYONE" in the sample included on the API site and it applies to user_huddle_changed and user_profile_changed. Seems like this might mean that user_change modeled above also needs a tweak on this field.

is_invited_user?: boolean;
has_2fa?: boolean;
locale: string;
presence: string;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be optional? Not seeing it in the user_huddle_changed sample event but the "this is the exact same thing as user_change` is tripping me up.

is_owner: boolean;
teams: string[];
};
two_factor_type: string;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like if has_2fa is an optional field, two_factor_type should be optional as well. I also don't see this in the event sample on the docs site

teams: string[];
};
two_factor_type: string;
has_files: boolean;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment as above

};
two_factor_type: string;
has_files: boolean;
is_workflow_bot: boolean;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment as above

two_factor_type: string;
has_files: boolean;
is_workflow_bot: boolean;
who_can_share_contact_card: boolean;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
who_can_share_contact_card: boolean;
who_can_share_contact_card: string;

@@ -937,6 +940,240 @@ export interface UserChangeEvent {
cache_ts: number;
}

export interface UserHuddleChangedEvent {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a lot to be desired with respect to the accuracy / completeness of the api site and I don't know how to make it better. We don't seem to even have a good public facing SOT for user_change to base off of since the example is incomplete so, "everything is identical to user_change" feels unhelpful to me personally.

@filmaj
Copy link
Contributor Author

filmaj commented May 10, 2022

Yeah... wow @srajiang I am now testing these events with an app and there are.. a lot of differences. I will try to address them in forthcoming commits as best I can...

@filmaj filmaj requested a review from srajiang May 10, 2022 19:15
@@ -920,7 +926,7 @@ export interface UserChangeEvent {
is_invited_user?: boolean;
has_2fa?: boolean;
locale: string;
presence: string;
presence?: string;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW I never saw this field in my testing of these three events

first_name: string;
last_name: string;
email: string;
email?: string;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Didn't see this field either, even though the "is_email_confirmed" field WAS present and it said "true" 🤔

@@ -882,11 +885,14 @@ export interface UserChangeEvent {
status_text: string;
status_text_canonical: string;
status_emoji: string;
status_emoji_display_info: [];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for catching that @seratch ! I think I have fixed that now.

@filmaj filmaj requested a review from seratch May 11, 2022 16:29
@seratch seratch merged commit 50f4d34 into main May 13, 2022
@seratch seratch deleted the new-user-change-events branch May 13, 2022 01:34
@seratch seratch modified the milestones: 3.12.0, 3.11.1 May 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement M-T: A feature request for new functionality semver:minor TypeScript-specific
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants