The setup-wasm-features function is the single source of truth for
resolving the renderer choice (URL param > profile preference > team
flags), storing the result in state[:features]. Several helpers were
re-deriving the same priority chain independently, duplicating logic:
- wasm-enabled?, wasm-url-override, wasm-url-override-ref
- enabled-by-flags?, enabled-without-migration?
This change removes all duplicated helpers and simplifies the
remaining functions to rely exclusively on the pre-computed
:features set:
- active-feature? — now just checks (contains? (:features state)
feature) without special-casing render-wasm/v1
- use-feature — uses the reactive features-ref for all features
- initialize/recompute-features effects — use the local features
binding directly
Since :features is rebuilt by setup-wasm-features on every
initialization and recompute, this preserves correctness while
eliminating ~50 lines of duplicated code.
Rename the icon file and fix the icon ID from "elipse" (single "l")
to "ellipse" (double "l") across the codebase.
The root cause was a mismatch: the icon file/ID was named "elipse"
but get-shape-icon returns "ellipse" for circle shapes. Since the
icon* component validates icon-id against the auto-generated
icon-list set, the string "ellipse" failed validation.
Changes:
- Rename frontend/resources/images/icons/elipse.svg to ellipse.svg
- Fix icon def in icon.cljs: ^:icon-id elipse -> ^:icon-id ellipse
- Fix deprecated icon in icons.cljs: ^:icon elipse -> ^:icon ellipse
- Fix usage in top_toolbar.cljs: deprecated-icon/elipse -> ellipse
- Fix usage in history.cljs: deprecated-icon/elipse -> ellipse
Signed-off-by: Andrey Antukh <niwi@niwi.nz>
The S3 storage backend uses DefaultCredentialsProvider which includes
WebIdentityTokenFileCredentialsProvider in its chain. However, that
provider requires software.amazon.awssdk/sts on the classpath to call
AssumeRoleWithWebIdentity. Without it, the provider silently fails and
credentials cannot be resolved when using IRSA on EKS.
Closes#9927
Signed-off-by: Joshua C <joshua.cullum@gmail.com>
Co-authored-by: Joshua C <joshua.c@data-edge.co.uk>
Co-authored-by: Andrey Antukh <niwi@niwi.nz>
`cls/show-in-viewer` unconditionally dissoc'ed `:hide-in-viewer` on the
interaction destination, so every `add-interaction`, `add-new-interaction`,
and `update-interaction` call silently re-enabled the destination's
view-mode visibility — even when the user had just deliberately hidden
that frame. Reporter (#9049) hid a board, dragged a prototype arrow at
it, and watched the board reappear in View Mode.
Make `show-in-viewer` a no-op when the destination already has
`:hide-in-viewer true`. The auto-unhide still fires on destinations with
no explicit hide flag (the original ergonomic — new prototype targets
default to visible), but explicit user intent is now preserved across
interaction-add / interaction-update.
Behaviour change: dropping the auto-unhide on explicitly-hidden
destinations matches the reporter's expectation ("nothing would show up
in View Mode unless explicitly marked as such") and the surrounding
`:hide-in-viewer`-aware UI in `measures.cljs`, which already lets users
toggle the same property directly.
Closes#9049.
Co-authored-by: Andrey Antukh <niwi@niwi.nz>
