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

BD-3477 Remove "send_id" for several message events #8105

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

rachel-feinberg
Copy link
Contributor

Summary

My PR removes send_id for a few SMS message engagement events

Related PRs, issues, or features (optional)

BD-3477

Feature release date (optional)

  • N/A

Contributor checklist

  • I confirm that my PR meets the following:
    • I signed the Contribution License Agreement (CLA).
    • My style and voice follows the Braze Style Guide.
    • My content contains correct spelling and grammar.
    • All links are working correctly.
    • If I renamed or moved a file or directory, I set up URL redirects for each file.
    • If I updated or replaced an image, I did not remove the original image file from the repository. (For more information, see Updating an image).
    • If my PR is related to a paid SKU, third party, SMS, AI, or privacy, I have received written approval from Braze Legal.

Submitting for review

If your PR meets the above requirements, select Ready for review, then add a reviewer:

  • Non-Braze contributors: Add braze-inc/docs-team as the reviewer.
  • Braze employees: Have any relevant subject matter experts (like engineers or product managers) review your work first, then add the tech writer assigned to your specific vertical. If you're not sure which tech writer to add, you can add braze-inc/docs-team instead.

Thanks for contributing! We look forward to reading your work.

@jeffreystutz
Copy link
Contributor

These fields were all empty historically, correct? I have no objection to us making the code change, but for cloud storage connectors we'll need to pre-announce the change, and we should keep the field in the docs until then. We can update the string to say that it's deprecated so that there are no questions about why it's empty/missing.

So I'd say let's do the following:

  1. Update the docs to say the field is deprecated
  2. Release the change to partners, since there shouldn't be any change anyway
  3. Get new PRs ready for making the code change for cloud storage and removing the field from the docs. Hold off on releasing until our next release, which will include communications ahead of time.

Does that work for everyone?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants