Changelog

v0.1.26 (20 October 2026)

• Event and LFG popups show once for the whole account, with Not going and Dismiss, and at most one every 10 minutes (#446; a member, 20 October 2026: "every time I logged into a character it would popup again asking for my interest ... a button upfront with not attending which dismisses it? -or a plan ol' dismiss").

  • Seen, account-wide: DecadesGuildOpsCache.popups.seen (Features/Popups.lua, rules in the pure PopupsLogic) keys each popup by event:<id> or lfg:<postId>. Once any character of the account was shown it, answered it (Not going) or dismissed it, no other character sees it. An entry is forgotten an hour after its event ends or its post expires (30 days when neither is known). The first login after the update merges what was already marked shown (the events' invited and LFG's match: toasts) into it, so nobody gets a flood.
  • The buttons: a new event's popup has Open, Not going (the answer Decline through GuildEvents:Answer, the usual rsvp record and message, as the character logged in; no reminder follows) and Dismiss (hidden for good without answering; the event stays on the Events page, where each row keeps its Decline). An LFG post's has Open, Hide today (that activity's LFG popups until local midnight, on every character) and Dismiss. Several at once are one popup with Open and Dismiss all. Widgets.Toast actions gain more = { { text, onClick } }: the extra buttons sit on a row under the message, and toast:RunExtra(i) is their click.
  • Less at once: during the login they are lines in the Welcome back card's new sections, "New events" and "Groups for you"; after it, at most one event or LFG popup every 10 minutes, and what came in between goes out together in the next one. One that never got its turn before logout is a line in the next login's card. Nothing in an encounter or a PvP match. Reminders for events answered Accept or Tentative (the account's answer, so an alt is reminded of its main's), the player's own LFG notices and confirmations are not limited.
  • Council's login card for events awaiting approval shows at once when one of them was never shown to any character of the account, else at most once a day on the account (eventApproval.lastSummaryAt), never on every character's login; the Review list and the sidebar count always have them.
  • Settings, Notifications (new, beside LFG): "New event popups", "LFG popups" (LFG's own switch, lfg.toastPosts, read-only when the Decades profile syncs it) and "Only popups for events and groups I can join" (an LFG group's level range and open roles; guild events carry no requirements). Self-test popups.buttons; verification docs/verification/446-popup-dismiss.md.

• The loot council's S/A assignments and STOPs reach the Decades app within seconds: the GuildOps link's lc kind (#441; John, for decades_app#88: council outside the raid confirms and stops assignments from the web and their phones, and a STOP is pushed to the raid leader's and the recipient's phones).

  • What: an S or A assignment's alert and every in-game STOP, Release and Reassign, each event carrying exactly its lc_assignment or lc_stop record's ids and fields (assignmentKey, stopId, op, ...), so the app joins the message with its record when the SavedVariables arrive. Lines DGO1 lc <reqid> <part>/<total> <chunk>, at most 4; several events a message (Features/LootLinkLogic.lua, LootLink.lua; the JavaScript codec tools/lclink/lclink.mjs, registered in tools/livelink/kinds.mjs).
  • One sender, never every witness, council+ only: a STOP, Release or Reassign goes from its maker's client in the click that made it (first in it, before the op's whispers, which nothing in the link can stop; the next click while another kind's message holds the link, never thrown away for ours); an assignment from the awarder's client when the awarder is council+ with GuildOps in the raid, else the lowest GUID of the council+ clients with GuildOps in the raid. Report receivers and STOP receivers never send.
  • From a click only (Forever's rule): an assignment waits for that client's next click on our own buttons, the toast's Send to Decades, the alert's Confirm, or a STOP, Release or Reassign, each carrying the queue. A burst is one toast, then the count after 3 s; each click sends the oldest events that fit one line (or every part, where this client's record allows it), at most 16 a message; the queue holds 40 events for 2 h 10 min, is offered again every 2 minutes while no toast is up, and goes only when the setting is turned off or a settled roster says we are no longer council+.
  • When it can't go: chat logging off asks for /chatlog, then Save request (live_request, kind = "lc"); nothing is offered or sent in a chat lockdown, and the toast comes once it lifts; the lc_* records still arrive at the next /reload.
  • Settings, Loot council: "Send loot council updates to the Decades app" (lootCouncil.link), on by default. What we collect's Loot council entry says so. LootStop:Release(sid, source?), :Reassign(sid, to?, source?) and :Stop(a)'s a.source mark our own button's click. Self-test lootlink.state; contract docs/desktop-app.md, "Loot council updates"; verification docs/verification/441-lc-link.md.

Earlier releases: https://github.com/Decades-Guild/decades-guildops-addon/blob/main/CHANGELOG.md