Initialise the project name / change number eagerly in gr-router
While the change and patch-sets were propagated to the views,
the project name wasn't, creating a situation where the components
do not know with which project they are associated.
The lack of awareness of the project forced the models to trigger
a change number to project lookup, which wasn't needed before.
Historically this situation has not been a problem because the
association of the view to a project/change was made by calling
explicitly the restApiService's setInProjectLookup() with change
number and project name. However, since I3a0694e5, the
responsibility to trigger the loading of the change details was
shifted from the _paramsChanged of the view to the event
listeners of the models, which surfaced the Issue 16354.
Recover the regression by making sure that the project / change num
lookup table is fully populated before routing events to their
respective events listeners.
The result is a faster execution by removing the redundant
backend API of lookup project by change-number and
a correct error is reported when the user is trying to access
a non-existent project name or change number.
Bug: Issue 16354
Release-Notes: Fix change screen loading of invalid project/change URL
Change-Id: If08e3fd745401568e82ecf26cbb481dd0544e0bf
diff --git a/polygerrit-ui/app/elements/core/gr-router/gr-router.ts b/polygerrit-ui/app/elements/core/gr-router/gr-router.ts
index 8c17285..0c3a637 100644
--- a/polygerrit-ui/app/elements/core/gr-router/gr-router.ts
+++ b/polygerrit-ui/app/elements/core/gr-router/gr-router.ts
@@ -308,6 +308,13 @@
}
setParams(params: AppElementParams | GenerateUrlParameters) {
+ if (
+ 'project' in params &&
+ params.project !== undefined &&
+ 'changeNum' in params
+ )
+ this.restApiService.setInProjectLookup(params.changeNum, params.project);
+
this.routerModel.updateState({
view: params.view,
changeNum: 'changeNum' in params ? params.changeNum : undefined,
