-
-
Notifications
You must be signed in to change notification settings - Fork 543
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Policy Violation Display Bug #2043
Comments
Thanks for reporting @SeanWrightFeat! Was able to reproduce and have a fix in the pipeline. Once again our ORM is shining with some quirky lazy loading behavior... As this is impacting a core feature of DT, We'll most likely push a bugfix release out for it. |
@nscuro thank you for getting onto this so quickly! I really appreciate it. Please shout if there's anything at all that I can do to help. |
DataNucleus would (in some, not all cases) falsely assume that the `violation.policyCondition.policy` field has already been loaded, and would not attempt to fetch it again. This then caused API responses to not contain the `policy` field (DependencyTrack#2043). The scenario is not reproducible in unit tests, even with regular cache eviction. It is reliably reproducible in running instances using the steps listed in DependencyTrack#2043 though. Instead of detachment like it's introduced in this PR, another cheap fix would've been to call `violation.getPolicyCondition().getPolicy().getName()` instead of `violation.getPolicyCondition().getPolicy()` in `PolicyQueryManager#getPolicyViolations`. That would force DN to fetch all fields of `Policy`, but I felt like that was too hacky to rely on it. Signed-off-by: nscuro <nscuro@protonmail.com>
@SeanWrightFeat The fix is now available with version 4.6.1 of the API server / bundled distribution. Release of the frontend was not necessary, so the latest version for that remains 4.6.0. Thanks again for reporting! |
DataNucleus would (in some, not all cases) falsely assume that the `violation.policyCondition.policy` field has already been loaded, and would not attempt to fetch it again. This then caused API responses to not contain the `policy` field (DependencyTrack#2043). The scenario is not reproducible in unit tests, even with regular cache eviction. It is reliably reproducible in running instances using the steps listed in DependencyTrack#2043 though. Instead of detachment like it's introduced in this PR, another cheap fix would've been to call `violation.getPolicyCondition().getPolicy().getName()` instead of `violation.getPolicyCondition().getPolicy()` in `PolicyQueryManager#getPolicyViolations`. That would force DN to fetch all fields of `Policy`, but I felt like that was too hacky to rely on it. Signed-off-by: nscuro <nscuro@protonmail.com>
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Current Behavior:
When viewing the Policy Violation of a project, it is not displaying the State or Policy Name in the table. When you delete the policy and recreate it, it then shows. However it disappears as soon as you change any view options on the table, such as sorting the items in the table or changing the amount of items to display.
Steps to Reproduce:
View the Policy Violation section of a project.
Expected Behavior:
Be able to see the State and Policy Name fields.
Environment:
Additional Details:
Here is a screenshot showing the issue:
The text was updated successfully, but these errors were encountered: