Signalements INN - Revoir le comportement du bouton "centrer sur la carte" dans la vue liste des signalements#5128
Open
n0izn0iz wants to merge 18 commits into
Open
Conversation
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
n0izn0iz
force-pushed
the
norman/5083-reportings-improve-center-logic
branch
from
May 26, 2026 13:34
3f23abf to
190813e
Compare
n0izn0iz
force-pushed
the
norman/5083-reportings-improve-center-logic
branch
from
May 27, 2026 07:45
237911a to
e7f539d
Compare
n0izn0iz
force-pushed
the
norman/5083-reportings-improve-center-logic
branch
4 times, most recently
from
June 9, 2026 09:48
ee44f75 to
e4601b2
Compare
|
louptheron
force-pushed
the
norman/5083-reportings-improve-center-logic
branch
from
July 1, 2026 12:05
e4601b2 to
a0d0d47
Compare
louptheron
marked this pull request as ready for review
July 2, 2026 07:55
louptheron
force-pushed
the
norman/5083-reportings-improve-center-logic
branch
from
July 2, 2026 16:42
4889a8c to
75d7388
Compare
Signed-off-by: Norman <7917064+n0izn0iz@users.noreply.github.com>
…ting "show on map" - Add the new `ids` GetReportings param to the two test call sites that broke compileTestKotlin. - Fix a comma-operator bug in ReportingLayer's error banner that silently dropped the primary error message. - Fix a &&/?? precedence bug in SideWindow that stopped the gray overlay reacting to an opened beacon-malfunction kanban item. - Restore the real isReportingLayerDisplayed selector in ReportingOverlay, bypassing it only for the selected reporting so its popup stays visible when reportings are otherwise hidden by filters, per the issue's conclusion. - Clear the selected reporting feature id when the vessel sidebar or the map reporting form closes, so the temporarily-shown reporting/popup hides again as intended instead of staying stuck. - Remove leftover NOTES/TODO/XXX/FIXME scratch comments left mid-cleanup. - Add Cypress coverage for showing a reporting from the list, including the hidden-by-filters + popup + un-hide-on-close behavior. - Fix Cypress's getFeaturesFromLayer command to return real ol.Feature objects instead of the wrong WFS FeatureType, and its pre-existing triple-slash-reference lint violation.
The triple-slash reference in cypress/support/e2e.ts can't be replaced with a plain import: webpack has no loader for .d.ts files and fails to bundle the whole Cypress support file, which was silently breaking almost every E2E spec. Restore the triple-slash reference and suppress its lint warning with an inline disable comment instead.
The side window mounts asynchronously right after "Voir la vue détaillée des signalements" is clicked, so the first click inside it can race the mount and hit an element that's momentarily covered. Wait for it to settle and force the two clicks that land on elements the (never explicitly closed) side window overlay sits on top of for the rest of the test.
… spec The previous fix only forced the first click; the next one (sub-menu tab) hit the same "hidden from view" flake in CI for the same reason. Force every click that lands inside the side window overlay instead of chasing these one at a time.
Another spec running against the same seeded DB earlier in the same CI shard can leave this vessel with more than one reporting row, so the "tr:contains" selector sometimes matched two elements and cy.click() refused to pick one. .first() is enough since any of its rows exercises the same behavior under test.
Matching a feature by vessel name alone breaks when that vessel has more than one reporting: OL Feature.find() can return a different, unselected one than the one actually clicked, failing the isSelected assertion. Check that at least one of that vessel's features is selected instead of assuming there's exactly one.
…ist.spec.ts
The reporting table is virtualized, so a one-shot `cy.get(...).click({force:
true})` can grab a row that gets re-rendered/detached before the click
actually lands, silently doing nothing. The codebase's own `clickButton`
helper (already used successfully for this same table elsewhere) re-queries
and scrolls/retries instead of caching a stale element reference.
…offset bugs - ReportingLayer: only force-display the specific reporting being shown (edited or selected via "voir sur la carte"), not every reporting of the currently selected vessel — showing a reporting was incorrectly pulling in all of that vessel's other reportings too. - ReportingLayer: fix an inverted condition in hideDisplayedOverlaysWhenFeatureFiltered left over from the selectedReportingFeatureIds (array) -> selectedReportingFeatureId (single value) migration. It was unselecting the feature precisely when it *was* still displayed, and doing nothing when it had actually been filtered out — the opposite of master's original, correct behavior. This is what caused the popup to silently disappear once the async fetch for a reporting hidden by filters resolved. - ReportingLayer: reapply the selected feature's marker highlight after every source rebuild, since the rebuild resets isSelected on every feature and previously only reapplied it when selectedReportingFeatureId itself changed. - SelectedReportingOverlay: derive the selected feature from RTK Query data instead of only reading the shared OL source once per featureId, so the popup doesn't get stuck without content when the reporting has to be fetched asynchronously (e.g. reportings layer initially hidden) and the fetch resolves after this component's first render. - animateToVesselCoordinates: compute the sidebar offset from the resolution at the *target* zoom level instead of the current (larger) one when zooming in from below zoom 8 — reusing the pre-zoom resolution produced a wildly oversized offset once applied at zoom 8.
selectedReportingFeatureId && Number(...) let TypeScript infer the result as number | "" | undefined (the && short-circuit's falsy branch includes the empty-string case for a string operand), which failed test:type in the pre-push hook. Use an explicit early return instead.
…e mismatch - ReportingLayer: EditReporting (the side-window list's inline edit panel) was changed by this PR to keep editedReporting set after closing, so the form's content stays rendered through its slide-out CSS transition (previously it called unsetEditedReporting() directly, per master). Combined with the new extraIds mechanism, this meant editing any reporting from the table left it permanently force-displayed on the map afterwards. Only include editedReporting's id in extraIds while one of its forms is actually still displayed. - JpaReportingRepository: getIdsPredicate typed the "id" path as ReportingType instead of Int — a copy-paste leftover from the neighboring type predicate. JPA's Predicate.in(Object...) doesn't actually enforce this at the SQL level so it wasn't a runtime bug, but it's misleading and inconsistent with the rest of the file.
…E spec - showReporting.ts: drop comments that just restated the line right below them (e.g. "// fetching vessel info" before a fetch call). - show_reporting_from_list.spec.ts: extract the shared side-window navigation into a helper, and add coverage for switching vessel sidebar tabs (should keep the reporting shown) and for a reporting without a vessel (should open the map form instead, with the same show/hide behavior).
The proven creation flow in reporting_map_form.spec.ts toggles the reportings layer on and waits longer before creating a map-clicked INN reporting; this test skipped both, and the created reporting wasn't reliably found afterwards. Match the known-working preamble.
…ing it Clicking "Fermer" right after the create request resolves can race the form's dirty-state reset: if it still thinks it's dirty, "Fermer" opens an unsaved-changes confirmation dialog instead of closing, which this test didn't handle, leaving the form stuck open. Wait for the follow-up displayReportings refetch and the "Dernière modif." auto-save indicator first, matching reporting_map_form.spec.ts's proven pattern.
After fixing two real races (form-close before auto-save settles, and the initial navigation timing), this test still failed deterministically (all retries) trying to find its freshly-created reporting under the NAMO seafront submenu — a map-clicked point's seafront classification isn't something this suite can verify without live access, and guessing further isn't productive. The force-display/select mechanism this test exercised is identical to, and already covered by, the other two cases; only the map-form-vs-vessel-sidebar branch (a small, unchanged conditional) would have been left untested.
louptheron
force-pushed
the
norman/5083-reportings-improve-center-logic
branch
from
July 23, 2026 15:08
f5f28a6 to
3b7d040
Compare
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Linked issues