Witchdoctor (and likely other CoA classes intermittently) never got the
"On curable debuff" border highlight on raid/party frames: the
C_Player.IsCustomClass() check in getCoaDispels could return false at
scan time and cache playerCoaDispels = false, after which the highlight
manual-scan path was never entered and the fallback RAID filter (which
doesn't know about COA dispel spells) silently returned nothing.
COA_CLASS_DISPELS only contains custom-class tokens (CHRONOMANCER,
WITCHDOCTOR, MONK = Templar, PROPHET = Venomancer, etc.) so any token
match already implies the player is a dispelling custom class — the
IsCustomClass call is redundant. Trust the table directly. Vanilla
classes whose tokens aren't in the table still get false → RAID filter
path, unchanged.
Bump v3.3.0-coa.2.
Marks this fork as carrying the CoAClassColors.lua patch, so users can
tell at a glance (e.g. via /reload addon list) that they are running the
guild-patched build. Suffix follows the coa-omen convention
(3.0.9-coa1).
SUF stores class colors in a private ShadowUF.db.profile.classColors
table seeded only with the vanilla 10 in defaultlayout.lua. On the
Voljin/CoA client _G.RAID_CLASS_COLORS is populated by FrameXML with
22 additional tokens (HERO + 21 CoA customs), but those never reach
SUF, so a guildmate's CoA-class health bar falls through to the
percent gradient.
New file post-hooks ShadowUF:OnInitialize, ProfileReset and
ProfilesChanged to copy any RAID_CLASS_COLORS entry the active
profile is missing into profile.classColors. Idempotent — only fills
nil keys, so user customisations and SUF's stock vanilla-10 values
win.
Source of truth is the live client's table, populated in
patch-B.MPQ → SharedXML/SharedConstants.lua, so the addon stays in
sync with whatever palette the realm ships without a hardcoded copy.
florian.berthold
andrew6180