uncomment apply_absolute_date

[acwhite211]

Fixes #7021

Uncomment apply_absolute_date line in the execution.py file. Looks like this line was commented out during development and needed to be added back it. This is to fix the issue of querying for collection objects based on the timestampCreated field in relative mode all records are returned, despite the timestamp created not falling within the designated range.

Checklist

• Self-review the PR after opening it to make sure the changes look good and
  self-explanatory (or properly documented)
• Add relevant issue to release milestone
• Add pr to documentation list
• Add automated tests
• Add a reverse migration if a migration is present in the PR

Testing instructions

• Create a specify query in the CO QB viewer. Set the query to filter by the "Timestamp created" and set some condition on that filter. See that the CO query results are limited and not returning all COs.
• Go through testing instructions from: Add series tool in query builder #4952

[emenslin]

• Create a specify query in the CO QB viewer. Set the query to filter by the "Timestamp created" and set some condition on that filter. See that the CO query results are limited and not returning all COs.
• Go through testing instructions from: #4952

---

Running into a similar issue as #4952 (review), if you check series, delete catalog number, then query series is still checked and you cannot check distinct and the count is incorrect.

07-11_13.15.mp4

Also I was able to replicate this issue #4952 (review) where if you check series then disable catalog number it throws an error.

07-11_13.46.mp4

Specify 7 Crash Report - 2025-07-11T18_46_43.554Z.txt

Other than those two issues everything else looks good

[acwhite211]

The first issue of removing catalog number and rerunning the query seems to be a front-end issue where the front-end is still putting smushed=True in the request. I remember that we solved this issue, so it's odd that it is happening again, I'm investigating the issue. The second issue of unselecting the catalog number is also causing the same issue.

[acwhite211]

@emenslin I fixed the issues that you found with removing the catalog number field in series queries. Good for retesting, thanks!

[emenslin]

Series checkbox not working properly for both new queries and saved queries. In a new query you can't seem to check the series checkbox, if you check it and try to query it unchecks:

07-14_12.59.mp4

With a saved query you cannot uncheck series:

07-14_13.02.mp4

[acwhite211]

Thanks @emenslin, made some changes to the logic to fix that issue. Looks like it's behaving correctly now. Should be good now to retest, thanks.

[emenslin]

• Create a specify query in the CO QB viewer. Set the query to filter by the "Timestamp created" and set some condition on that filter. See that the CO query results are limited and not returning all COs.
• Go through testing instructions from: #4952

---

Looks good, all previous issues seem to be fixed!

[lexiclevenger]

Testing instructions

• Create a specify query in the CO QB viewer. Set the query to filter by the "Timestamp created" and set some condition on that filter. See that the CO query results are limited and not returning all COs.
• Go through testing instructions from: #4952

---

No issues with the series checkbox, but it looks like the results are inaccurate and include records with timestamps outside the conditions:

Screen.Recording.2025-07-15.at.12.05.31.PM.mov

https://kufishtissue20240124copy-issue-7021.test.specifysystems.org/specify/query/188/
KU Fish Voucher Collection
spfishadmin

[bhumikaguptaa]

• Create a specify query in the CO QB viewer. Set the query to filter by the "Timestamp created" and set some condition on that filter. See that the CO query results are limited and not returning all COs.
• Go through testing instructions from: #4952

All of the testing instructions works as expected, but I ran into a separate issue with the series box : #7086

[acwhite211]

Thanks for noticing that @lexiclevenger! Looks like this is an issue in main and other older version of Specify. I created a new issue #7088, so we'll ignore that issue for this PR. Thanks!

[lexiclevenger]

@acwhite211 In that case, looks good!