agreed. for the time being, i manually put the filter in my queries:

          AND (publishStartDate <= CAST("'.date('Y-m-d\TH:i:s').'.000'.date('P').'" AS DATE) OR publishStartDate IS NULL)
          AND publishable = true

but this is an awful hack and if you add another voter, you would have to update all queries. just while looking for this example i realized that i missed this in one place.

we could do some helpers or a phpcr-odm listener maybe (if there even is a query event). but the workflow itself is independent of storage layer, so its a bit tricky...

what would be cool if we would provide some decorators for this .. ie. the decorators could be provided by the same package as the voter. it could then either add the necessary filters to the query or if its not possible to execute the logic as a query filter, it would then decorate the result set to apply the filters on iteration

yep, that sounds right. does the code creating the query need to know about them, or can this automatically happen inside phpcr-odm?

this is probably more of a "stretch goal" for 1.3 ..