Fix admin view saving permission

[AaronPlave]

Summary

Fixes plan view menu save button disabled state to ensure admins can save views they do not own.

Details

The view menu save button was explicitly gating view save on view ownership. Now the button ties into actual permission to perform a view save. Additionally, there was a subtle svelte reactivity issue with hasUpdateViewPermission computation in the parent +page.svelte where the view store was being reactively updated twice within one reactive pass and the second write was not explicitly declaring that it wrote to the store (initializeView) so the svelte compiler didn't see any reactive dependencies and therefore didn't mark the store as dirty the second time. This meant that as an admin AND the owner of the view, upon page load, the save button would be disabled with a tooltip warning of a lack of update permissions when in reality the user did have update permissions. Upon view update, the issue would correct itself. The solution here was to move the initialization of the view above the computation of the hasUpdateViewPermission so that the view is fully set before hasUpdateViewPermission receives it initially.

Visible UX Changes

• Admins can save views they do not own.
• Admins do not see an incorrect tooltip on disabled save button on page load

Verification

• Open a plan as an admin
• Load a view that your user does not own
• Ensure that if the view has no changes (if it does, save it and reload)
• Ensure that upon making changes to the view, you can save the view
• Reload the page and ensure that the tooltip on the disabled save button (because the view has no changes) does not appear
• Switch to the user role and verify that you can save only your views
• Switch to the viewer role and verify that you cannot save any views

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud