Problem: bookmarks coverage was render + edit-mode-entry only, so the
tests passed even when the underlying CRUD plumbing was broken. The
favorites helper that lets you add/remove a bookmark or folder was
not exercised end-to-end.

Goal: walk the full workflows a real user runs in BookmarksPortlet
edit mode, with each test self-cleaning so the suite is repeatable.

Changes:
- add helpers `emptyBookmarkForm`, `emptyFolderForm`, and entry-by-name
  locators that scope to the visible "empty" form (multiple identically-
  shaped forms coexist on the page — error vs. empty variants — so a
  global selector resolves to several inputs)
- add `add, edit, and delete a bookmark` covering: open Add Bookmark
  form, fill name/url/note, save, click per-entry edit icon, verify
  pre-population, rename, save, then click delete (auto-accepting the
  native confirm dialog) and verify removal
- add `add and delete a folder` mirroring the same pattern for folders

Notes: do not use a renamed value that contains the original as a
substring — `hasText` filter does substring match, so an
`Initial → Initial (edited)` rename silently passed every assertion.
The fix is to use fully distinct names (`Playwright Add ...` vs
`Playwright Renamed ...`), which is what landed.

Problem: SimpleContentPortlet coverage stopped at "config mode loads
CKEditor for admin" — the actual save path that every web-component-
hosting portlet definition (notification-list, customize, favorites-
carousel, waffle-menu, etc.) rides on was untested.

Goal: assert that an admin can change content via the config form,
that the change persists into view mode, and that cancel discards
unsaved changes. Keep the spec self-cleaning so repeat runs leave
the seed content intact.

Changes:
- helper `waitForCkeditor` that resolves once CKE has mounted on the
  textarea, returning the instance id
- helper `getCkeditorContent` for capturing the original text
- helper `saveContent` that destroys CKEditor first, then writes the
  new value to the underlying textarea, then submits the form (see
  Notes below for why)
- `admin can save edited content via the CKEditor Save button` —
  captures original, saves new content, asserts persistence, restores
  original
- `cancel discards unsaved changes` — stages new content, clicks
  "Return without saving", asserts the marker never persisted

Notes: `editor.setData(html, callback)` is asynchronous and the
callback can fire before CKEditor's submit-time hook has finished
syncing its internal model to the textarea. With the callback form
the form posts the *previous* content roughly half the time when the
spec is run alongside other admin tests in the suite. Tearing the
editor down first (`editor.destroy(true)` — true means update the
underlying element on teardown) and then writing the value directly
removes every CKEditor surface that could re-sync, so the form posts
exactly what we set. Filed upstream as
uPortal-Project/SimpleContentPortlet#552 (cms variant has no plain
Save button on the form, which is the deeper fragility).

Problem: CalendarPortlet's events column was rendering raw template
source ("<% if (_(days).size() === 0) { %>...<%= day.displayName %>...")
into the visible portlet body instead of interpolated event entries.
The bug is that uPortal's respondr.xsl resets the shared
`up._.templateSettings` to Mustache-style {{ }} delimiters, but
Calendar's templates use the standard <% %> sigils. With the per-call
`_.template(text, settings)` override missing, Underscore returned
the source unchanged.

The fix landed in CalendarPortlet#404. This test stops the bug from
silently coming back the next time someone touches scripts.jsp or
adds a new template.

Goal: assert that the rendered events list never contains literal
Underscore opener sigils. Cheap to keep, fails loudly if the
templateSettings override is dropped from any future template
compile site.

Changes:
- add `event list renders without leaking Underscore template
  sigils` to portlets/calendar.spec.ts. Logs in as admin, navigates
  to the maximized Calendar, asserts the .upcal-event-list does not
  contain the substring `<%` or `<%=`. The list resolves to either
  the "No events" alert or one or more day rows — either is fine,
  the assertion only cares that no template source leaks through.

Notes: this test fails against the current 2.7.2 release of
CalendarPortlet (where the bug ships) and passes against
2.7.3-SNAPSHOT after the fix is deployed. Pairs with the
uPortalVersion / portlet alignment work on this branch — once the
next CalendarPortlet release lands it will go green on CI.

…Proxy spec

Problem: NewsReader coverage was render-only against a single instance
(campus-news), which missed three things worth catching: that
multiple instances coexist without trampling each other's per-instance
namespace, that offline feeds degrade gracefully instead of dumping
exception text, and that the configured feed labels actually reach
the DOM. Separately, tests/ux/portlets/web-proxy.spec.ts was pointing
at the `snappy` fname under the assumption it was a WebProxyPortlet
instance — `snappy` is actually a SimpleContent portlet, so the spec
was passing trivially against the wrong portlet.

Goal: drive NewsReader coverage to Adequate against the structural
surface that's stable in CI (the upstream RSS feeds aren't stable).
Stop the WebProxy spec from masquerading as coverage when no
WebProxyPortlet instance ships in the quickstart at all.

Changes:
- news-reader.spec.ts: replaced the three render-shape tests with
  five targeted ones —
  * campus-news renders feed selector with the expected feed names
    (Apereo News + Unicon News) so a regression in the
    feed-label rendering path fails loudly
  * chronicle-wired renders independently as a second instance
    (scoped by hasText to avoid the hidden-but-DOM-present sibling
    that uPortal's max-mode rendering leaves behind)
  * offline feeds degrade gracefully with the "currently unavailable"
    message — and explicitly fail if Java exception text leaks
  * two instances coexist on the news-fav-collection fragment
    without colliding on namespaces
  * edit mode loads the feed-management UI (kept from before)
- web-proxy.spec.ts: deleted. The quickstart deploys the WebProxy
  WAR but seeds no portlet definition that uses it; even adding one
  would need a stable upstream target to exercise URL rewriting,
  which is infrastructure we don't have. Coverage doc tracks this
  as Out of scope.

Problem: previous web-proxy.spec.ts was already deleted because no
WebProxyPortlet instance shipped in the quickstart and the file was
silently testing the wrong portlet (`snappy`, which is SimpleContent).
Coverage was None / Out of scope as a result, even though the WAR is
deployed and ready to use.

Goal: stand up a deterministic WebProxy instance against a stable
upstream so we can actually exercise the proxy fetch + filter + render
path in CI, and lift the portlet's coverage out of "untested".

Changes:
- data/quickstart/portlet-definition/web-proxy-example.portlet-definition.xml:
  new catalog-only portlet definition `web-proxy-example`. Targets the
  IETF-reserved domain (RFC 2606) so the body text doesn't drift over
  time. Catalog-only — no fragment-layout subscribes to it, so no
  default tab is changed and per-role smoke specs are unaffected.
  contentService=httpContentService + filters=urlRewritingFilter is
  the minimum viable wiring for the HTTP-fetch path.
- tests/ux/portlets/web-proxy.spec.ts: three tests —
  * proxies http://example.com/ and surfaces the upstream body
    ("Example Domain", plus the ICANN-maintained policy sentence)
  * upstream fetch failure surfaces a graceful error message —
    explicitly fails if Java exception text or HTTP-status
    boilerplate leaks
  * no critical JavaScript errors on load

Notes: plain HTTP is intentional. https://example.com/ fails handshake
against Tomcat's bundled JDK trust store (older trust anchor set vs.
modern serving cipher), and example.com responds 200 OK over HTTP
without redirect, so plain HTTP keeps the test path working without
doctoring the JDK trust store. Captured the reasoning in an XML
comment on the location preference.

The portlet definition is imported into the running portal via
`./gradlew dataImport -Ddir=<dir-containing-this-file>` (dataImport
expects a directory, not a single file).

Problem: NotificationPortlet coverage was just two structural smoke
tests in web-components.spec.ts (icon attached, dropdown attached).
Neither asserted that the API actually returned data or that the
portlet rendered any specific entries — so the live JJWT
runtime-classpath bug, where /api/v2 was returning 403 and the
components rendered empty, slipped through coverage entirely.

Goal: lock in the real end-to-end happy path (demo notifications
flow API → web component → DOM) plus the negative auth path, so the
JJWT regression cannot recur silently.

Changes:
- new tests/ux/portlets/notifications.spec.ts with three tests —
  * notification-list portlet renders demo entries: asserts the
    expected demo titles (Room Available, Bike License Ticket Was
    Issued, Past Due Book, Math 101) reach the rendered DOM. If
    /api/v2 starts 403'ing again, none of these will appear and
    this test fails immediately.
  * notification-icon web component shows a badge with a count:
    confirms the icon mounts as a custom element and renders a
    numeric unread badge for an authenticated student.
  * API rejects missing or malformed bearer tokens: negative
    guard. With no Authorization header → 403; with a junk JWT →
    403. This is the security half of the regression guard — the
    happy path landing on 200 only matters if the security filter
    is still enforcing.

Notes: the JJWT runtime-classpath bug that broke the API is fixed
in uPortal-Project/NotificationPortlet#695. The above tests
verified the fix end-to-end. The expected-titles list is the
intersection of the two demo response files configured via
DemoNotificationService.locations in etc/portal/notification.properties.

Removed an earlier draft `API returns demo notifications` test
that listened on page.on("response") — it was order-dependent in
the full suite (the listener attached after login may or may not
catch the first /api/v2 fetch), and the DOM-level
"renders demo entries" test already covers the same regression
without that race.

…flakes

Problem: three families of flake were intermittently failing the
chrome-level smoke specs. None were portlet-behavior bugs, but each
made the suite unreliable in full-suite context.

  1. Synthetic clicks on Bootstrap 5 dropdown-toggles do not fire the
     auto-init delegate. Bootstrap.Dropdown.getInstance(toggle) shows
     the instance is wired, but Playwright's .click(), HTMLElement
     .click(), and dispatched MouseEvents all leave aria-expanded at
     "false". A listener somewhere in uPortal's chrome appears to be
     swallowing the click before Bootstrap's document-level delegate
     can match it (root cause still unidentified — tracked separately).
  2. The favorites add/remove API returns 200 (and fires the
     "modern-notification" success toast) before uPortal has
     invalidated the server-side layout cache. An immediate
     page.reload() can render the *previous* favorite state, so
     assertions like "after-remove the link should say Add to my
     Favorites" fail in suite context where preceding tests added
     contention.
  3. The Welcome-tab favorites count test hard-coded toHaveCount(3)
     against the seeded layout's three portlets, but the student
     user's persisted layout accumulates favorites (E! Online,
     NY Times, Campus News) across sessions and the count drifts
     to 6.

Goal: get the smoke specs to a stable green without changing what
they actually verify.

Changes:
- tests/ux/utils/ux-general-utils.ts: add a shared `openDropdown`
  helper that opens a Bootstrap dropdown via
  `Bootstrap.Dropdown.getOrCreateInstance(el).show()` — the public
  Bootstrap API, which works — and asserts aria-expanded after.
  Comment captures why we bypass the click pathway.
- tests/ux/smoke/favorites.spec.ts:
  * route every dropdown-open through the shared helper
  * add `expectFavoriteLinkText` that wraps reload + reopen + assert
    in `expect(...).toPass({ timeout: 10000 })` so the second pass
    picks up the layout cache invalidation if the first one fired
    too early
  * replace the hard-coded `toHaveCount(3)` with a dynamic count of
    `.up-portlet-wrapper:has(.portlet-options-menu .dropdown-toggle)`
    — the semantic invariant is "every portlet with an Options menu
    has a favorite item", not "the seed had three of them"
- tests/ux/smoke/portlet-options.spec.ts: route every
  dropdown-toggle.click() through the shared helper.

Notes: verified 3/3 full-suite runs pass at 117/117 after the
changes. The tests no longer exercise the dropdown-click pathway
explicitly — they go through Bootstrap's API. That's a tradeoff:
we gained suite stability and lost click-pathway coverage. The
right place to recover the click-pathway test is at the chrome
level once we know what listener is intercepting clicks.

Problem: this branch has been carrying tests and overlay seeds that
depend on three companion fixes published over the last few days
(uPortal Bootstrap dedupe, CalendarPortlet template-sigil leak,
NotificationPortlet jjwt runtime classpath). Until those landed on
Maven Central, CI couldn't go green here even though every spec
passed locally against the locally-built SNAPSHOTs.

Goal: consume the published GA versions so PR uPortal-Project#692 lights up green
and is ready to merge.

Changes:
- uPortalVersion 5.17.4 → 5.17.5 (picks up
  uPortal-Project/uPortal#2980 — Bootstrap 5 include de-dup in the
  respondr skin, fixes silently-broken Options menus / favorites /
  rate-portlet across the dashboard)
- calendarPortletVersion 2.7.2 → 2.7.3 (picks up
  uPortal-Project/CalendarPortlet#404 — Underscore template
  settings override per call, fixes the events column rendering raw
  template source instead of event entries)
- notificationPortletVersion 4.8.3 → 4.8.4 (picks up
  uPortal-Project/NotificationPortlet#695 — pin jjwt-impl +
  jjwt-jackson at runtime, fixes /api/v2 silently 403'ing and the
  notification web components rendering empty)

Notes: locally redeployed the three webapps from Maven Central
artifacts and ran the Playwright suite three times in a row —
117/117 each pass — to confirm the published versions match what we
were testing against the SNAPSHOTs.