_blogs
// blogs / 20260610.md
// blogs / 20260610.md
Dev Log: June 10 Wrap-up
Overview
Today was mostly about plumbing—specifically, cleaning up how our CRM modules handle queries and making the whole filtering system a lot less brittle. I spent a good chunk of time moving logic around to keep things DRY and finally fixed a nagging issue with how we negate search filters.
What I Worked On
Making Queries Smarter
I spent the morning diving back into our query utility logic. We had this annoying edge case where negating an empty string (using the ! prefix) wasn't behaving right. If a user wanted to find records where a field wasn't empty, the system would sometimes trip over itself.
I also added some logic to handle date range parsing more gracefully. Now, instead of requiring multiple parameters, the system can spot a range pattern—like value1_value2—and automatically turn it into a proper range expression. It’s a small quality-of-life win for the frontend team that makes our API way more flexible.
Here’s a sanitized look at how I handled that negation logic for empty fields:
// When we see a negation on an empty value, we're essentially
// looking for records where the field is actually populated.
if (isNegated && newVal.equals("")) {
return query.and(
new Expression(targetField, OP.EXISTS, true),
new Expression(targetField, OP.NOT_EQUAL, "")
);
}
Refactoring and the DRY Struggle
I realized that my decorators for customers and deals were essentially copy-pasting the same normalization logic. DRY (Don't Repeat Yourself) is a principle for a reason, so I spent the afternoon migrating that shared logic into a centralized helper.
I also finished implementing the GET_SUM and GET_COUNT query types for the customer and deal modules. It's much cleaner now; instead of the decorators being bloated with database logic, they just hand off the heavy lifting to the helper classes. It makes the code way easier to read, though I did manage to break the build for ten minutes because I missed a semicolon during the migration. Classic.
Restoration Work
There was also some cleanup needed in our BPMN integration. I had to restore some decorator logic that handles what happens after a record is added—specifically making sure the workflow engine gets the signal to start the next process. It's a lot of moving parts, but it's finally starting to feel cohesive.
Wrapping Up
Most of the heavy lifting for the CRM query refactor is done. Tomorrow, I want to double-check the logging to make sure we aren't swallowing any useful info during the normalization process, and then I can hopefully move on to some of the new feature requests. Catch you then.