While writing the code to edit/delete roles, I noticed that the message spec for the change_roles message type causes the app to crash if a role is deleted. The reason for this is when a user's role
is changed, we write the following information to the DB in the content field:
{"userIDs":["83813"],"newRole":"84094"}
To generate the robotext for this message in chat (so we can show users something like 'jack assigned max the "Moderators" role'), we introspect into threadInfo.roles and try to access the role info using the newRole ID. When a role is deleted, we delete it from the database, and so the threadInfo will no longer have this role info and the app will crash. To resolve this, we should now store the roleName associated with the role change in the DB to use as a fallback option.
We want to continue trying to access the role name via the threadInfo (since older clients will not have this roleName field), but fallback onto it if needed. The reason this should not cause a problem is that older clients are guaranteed to have the role stored in threadInfo since at the moment, only Members and Admins are roles on Comm, and neither are deletable.
As for the code, the following is done:
If the client has the newest code version, show them the robotext accessing the role either through threadInfo or the content field as a fallback.
If the client does not, then we just shim the message.
Depends on D8478