fix(events): show event descriptions for keys with special characters

[LaNinja06]

Problem

Event descriptions set in Data Manager render blank on the Events page for events whose key contains . $ \ & < > " '. Plain keys work, which made the issue look intermittent.

Editing such an event also had a second symptom: an event whose key contains & would be saved back as a & b, forking a second drill_meta / events.map entry that shows up as an undeletable duplicate ("ghost") row in the Data Manager events table.

Root cause

Two independent escaping bugs that happen to produce the same blank-description symptom:

1. . $ \ — the Events page unicode-escaped the event key (. → ., $ → $) before looking it up, but events.map is keyed raw, exactly as the key appears in events.list. The lookup missed.

2. & < > " ' — common.returnOutput → escape_html(str, true) HTML-escapes every string key and value in every API response. The events store decoded res.list but not the keys of res.map, so map[selectedEventName] compared a raw key against an escaped map. escape_html only touches charCodes 34/38/39/60/62, so dots and dashes passed through untouched — hence the "only some events" appearance.

The ghost rows come from the same escaping: the event detail page's Edit event button and the bulk visibility action read values straight out of the store (i.e. still API-escaped) and submitted them back as-is.

Changes

frontend/express/public/core/events/javascripts/countly.details.models.js

• getEventLongName / getLabels: look the key up raw instead of unicode-escaping it.
• setAllEventsData: normalize list and the map keys together. This is the one point both fetch paths commit through, so it also fixes fetchRefreshAllEventsData never decoding list at all. The now-redundant decode in fetchAllEventsData is removed.

plugins/data-manager/frontend/public/javascripts/countly.views.js

• handleEdit: decode key / e / name / description / categoryName and segment names before opening the drawer, and deep-copy segments (previously assigned by reference, so drawer edits mutated the store).
• handleChangeVisibility: decode row.key before submitting.

The decode set in handleEdit deliberately mirrors the file's existing, already-correct dm-open-edit-event-drawer handler, which is the path the events table uses to open the very same drawer. The bug was that the detail page's button did not do the same thing.

Verification

Two harnesses that lift the real shipped functions out of the files and run them against a payload built by modelling escape_html, so before/after is measured on actual code rather than a re-implementation.

Read path (description resolution, 18 keys incl. dots, $, backslash, &, &&, quotes, apostrophe, angle brackets, %, #, emoji, accents):

	before	after
synthetic set	12 passed, 6 failed	18 passed, 0 failed
dump from a real dev app	—	6 passed, 0 failed

The 6 baseline failures were exactly the & < > " ' family.

Write path (ghost rows), 10 keys:

	before	after
key submitted intact by handleEdit	4/10	10/10
name/description/category intact	0/10	10/10
key submitted intact by handleChangeVisibility	4/10	10/10

node --check and eslint clean on both changed files.

Notes

• EventsGroupsTabView has the same raw-row.key pattern but is not affected: event group ids are [CLY]_group_ + an md5 hex digest, which cannot contain the escaped characters.
• An additional events.map write in the enterprise /i/data-manager/event/edit handler was investigated and dropped — the drawer fires core /i/events/edit_map first and that already persists name/description, so the extra branches were unreachable and added a second whole-map read-modify-write with clobber risk. No enterprise-plugins change is needed for this case.