Summary

To allow T315926: Provide a way to search all of the XFF addresses listed in the XFF string, we need to make it possible to store each XFF IP as it's own distinct IP hex value

Background

• The CheckUser result tables currently store each XFF string as both:
  • The raw XFF string
  • The last XFF IP using hexadecimal
• To allow T315926: Provide a way to search all of the XFF addresses listed in the XFF string to be implemented, we need to store all the IPs as separate XFF IP values
  • This likely means having a separate table(s) so that we can have a one-to-many or many-to-many relationship to each CheckUser result table
  • However, we could also consider making the xff_hex column store comma separated values and use a LIKE query, or even have multiple xff_hex columns (relying on the idea that the XFF string won't be too long)

Acceptance criteria

• The necessary schema changes are agreed and applied to the master branch of CheckUser
• A Schema-change-in-production ticket is filed for these changes