Bug/66611 activerecord statementinvalid in get api v3 queries queriesapi queries id and get api v3 queries queriesbyprojectapi projects id queries default #20590
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ticket
https://community.openproject.org/wp/66611
What are you trying to accomplish?
Enable baseline to work flawlessly with the changes to the WP.allowed_to scope.
What approach did you choose and why?
Baseline before worked by manipulating the AR/arel structure to replace references to the model table (e.g.
work_packages
) by references to the journals (e.g.work_package_journals
). With the changes toWorkPackages.allowed_to
, the work packages eligible to be filtered are determined beforehand, on the current work packages, based on the currentproject_id
. But when filtering historic data, theproject_id
might have been a different value. Therefore, the filtering for the allowed work packages has to happen on the data the query is run for, which is stored in the data journals (e.gwork_package_journals
).The filtering for allowed work packages happens in a series of CTEs:
Before this PR, the resulting "allowed_by_projects_and_work_packages" was then used to retrieve all work packages by using
WorkPackage.from("allowed_by_projects_and_work_packages work_packages"
. But this fails because of the manipulations done for the historic query.By switching this to a simple
WHERE EXISTS (SELECT 1 from allowed_by_projects_and_work_packages ...)
the query itself is valid again but fails to filter on the historic project_id as described above.Instead of attempting to work this change into the existing structure another approach is taken. What the query understands as
work_packages
is redefined by placing a CTE under that name at the very top of the CTEs. Doing so will lead to all later CTEs as well as non CTE queries within the statement to understandwork_packages
as whatever the CTE defines instead of the also existingwork_packages
table. The redefinition ofwork_packages
is then a join statement on the journals of the timestamp(s) in question:Doing so solves the problem while at the same time greatly simplifying the code because the substitution happens at one central place within the SQL.
The only place which still needs to be adapted are WHERE statements on custom values which still need to be rewritten.
Merge checklist