feat(intercom): separate chat per org

[sentaur-athena]

Intercom creates a chat group per user. A user can access history of all their chats.
By defining user id that is user_id-org_id, we make intercom create a chat group per user<>org pair. That way a user only has access to their chat history from org A on org A and not their other orgs.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit d81e79f. Configure here.}

[github-actions]

Backend Test Failures

Failures on 12ed624 in this run:

tests/sentry/api/endpoints/test_organization_intercom_jwt.py::OrganizationIntercomJwtEndpointTest::test_get_jwt_success — log

[gw1] linux -- Python 3.13.1 /home/runner/work/sentry/sentry/.venv/bin/python3
tests/sentry/api/endpoints/test_organization_intercom_jwt.py:42: in test_get_jwt_success
    assert user_data["userId"] == str(self.user.id)
E   AssertionError: assert '6-4557934876753952' == '6'
E     
E     - 6
E     + 6-4557934876753952

[sentaur-athena]

I should most probably not expose user and org ID and just encode a string from it. 😅

[wedamija]

This means they'll lose history for any old chats. Is that a problem?

[sentaur-athena]

@wedamija this product is not launched yet. You mean they lose the history before this code change right? Then yes, that's ok.

[michelletran-sentry]

Is this an Intercom specified format? If so, can we add the Intercom documentation link for this? Otherwise, if we're specifying the format, we might want to consider not using md5, as it's known for hash collisions.

[sentaur-athena]

@michelletran-sentry no, this was a choice. They don't expect any format. I just wanted to generate a unique string per {user and org} pair.

[michelletran-sentry]

If we're specifying the format, then the risk is potential hash collision for legitimate compound strings (quite low, but might happen). The JWT is tamper-proof because it's signed, so using a readable id should be fine. I would suggest using the compound key directly. If you would like to preserve obfuscation, then using SHA256 will be less prone to collisions.

@sentaur-athena and I synced offline and it seems that compound keys should be fine.

[sentaur-athena]

Awesome. Thanks for the help. I'll go back to commits ago where this as not encoded.