I've been banging my head against a distracted cabal of developers who seem to think that a particular CiviCRM core design, which I'm invested in via my contributed code, is bad, and that it's okay to break it. This post is my attempt to explain why it was a good idea in the first place. The design in question is the use of a hash function to populate a field called 'invoice_id' in CiviCRM's contribution table. The complaint was that this string is illegible to humans, and not necessary. So a few years ago some code was added to core, that ignores the current value of invoice_id and will overwrite it, when a human-readable invoice is generated. The complaint about human-readability of course is valid, and the label on the field is misleading, but the solution is terrible for several reasons I've already written about. In this post, I'd like to explain why the use of the hash value in the invoice_id field is actually a brilliant idea and should b...