Careful with this. This would disappear adjustments with the same dateCreated that are added to a TreeSet or TreeMap.

Note that the ordering maintained by a set (whether or not an explicit comparator is provided) must be consistent with equals if it is to correctly implement the Set interface. (See Comparable or Comparator for a precise definition of consistent with equals.) This is so because the Set interface is defined in terms of the equals operation, but a TreeSet instance performs all element comparisons using its compareTo (or compare) method, so two elements that are deemed equal by this method are, from the standpoint of the set, equal. The behavior of a set is well-defined even if its ordering is inconsistent with equals; it just fails to obey the general contract of the Set interface.

https://docs.oracle.com/javase/8/docs/api/java/util/TreeSet.html

I usually do something like this

    @Override
    int compareTo(OrderAdjustment obj) {
        return dateCreated <=> obj?.dateCreated ?:
                lastUpdated <=> obj?.lastUpdated ?:
                        id <=> party.id
    }

This feels like a case where the default sort order of the association would make sense.

Either in the domain class

class OrderAdjustment {
    static mapping = { 
        sort dateCreated : "desc"
    }
}

Or in the association on Order

class Order { 
    static mapping = {
        orderAdjustments(sort:'dateCreated', order:'desc')
    }
}

I followed your solution with compareTo with fallbacks

Are there other places where we display order adjustments?

I can see them on order/print

orderInstance?.orderAdjustments.findAll { !(it.orderItem || it.canceled) }.sort { it.totalAdjustments }.reverse()

@alannadolny Ok cool. Can you include that in the ticket (@ Manon) with 1) a brief description of what is happening in that code 2) question on whether these need to be sorted as well?