Renaming a tag changes its id - the id is a slug of the display name -
and with it the `$label:` keyword the tag is stored under. The rename
migrated the keyword on every message but left Sieve rules naming the old
id, in both the generated `addflag` line and the metadata block the visual
editor reads back. The rule then went on tagging new mail under an id no
definition names any more: the tag renders as its raw id in grey and a
search for the renamed tag misses everything that arrived since, which
reads as the filter having quietly stopped working.
`renameKeywordInRules` rewrites every `add_label` action naming the old id,
disabled rules included. An external rule reaches the script through its
verbatim `rawBlock`, so that is rewritten too - but only the operand of an
`addflag`, since a test comparing a header against the same literal is the
rule's own logic rather than the tag it applies.
The store fetches, rewrites and uploads the account's active script on its
own rather than through fetchFilters/saveFilters, so a rename from the tag
settings cannot disturb which account an open filter view is showing; that
view is updated in place when it shows the same account. The write still
runs through the same plugin pipeline a save does, or a plugin's managed
section would be dropped from the script this activates. A script that is
not the active one is left alone entirely: writing to it would activate it,
and a tag rename must not switch someone's filters back on.
Whatever still names the old tag in the script that ends up being written -
a rule kept verbatim, a test comparing against the keyword, a section a
plugin just grafted back on - is counted, and the tag settings warn that
some rules still use the old tag, because only the user can fix those.
Mail delivered between the message migration and the rewrite was still
tagged by the old rule, so a successful rewrite is followed by one more
migration sweep, which no rewritten rule can race any more.
Switching folders currently keeps an active search applied and re-runs
it in the newly selected folder — deliberate behavior from #553, where
users wanted the query to follow them across folders. Others expect the
opposite: clicking Inbox/Sent should drop the search and just browse the
folder.
Add an opt-in setting (Settings → email behavior) that reconciles both.
Default is off, so #553's search-follows-you behavior is unchanged for
everyone. When on, any folder click clears the text query and advanced
filters and browses the folder instead of re-running the search.
Applied uniformly across the four folder-entry paths in MailApp — normal
mailboxes, per-account (Pro sidebar) folders, unified views, and cross
views — via one helper so no path diverges.
Opening the toolbar feeds its height back into scrollTop so rows keep
their position on screen. At the top of the list there are no rows above
to hold steady, so that scroll instead slides the first message under the
toolbar — select the top message and it disappears behind the bar acting
on it.
Skip the compensation when the list is already at the top and let the
content move down there, which is what the toolbar taking up space
should do. Mid-list behaviour is unchanged, and the scroll is clamped at
zero so collapsing the toolbar cannot drive it negative.
Recurring events defaulted skip:"omit"+rscale:"gregorian" on every rule,
which Stalwart serialises into the CalDAV RRULE as RSCALE=GREGORIAN;SKIP=OMIT.
DAVx5 rejects that ("Invalid recurrence rule"), breaking Android sync. Those
RFC 7529 fields only matter for non-Gregorian scales / invalid-date handling,
so stop emitting them for plain Gregorian rules.
- lib/recurrence-rule.ts: createRecurrenceRule() helper with no skip/rscale.
- CalendarRecurrenceRule.rscale/skip are now optional.
- event-modal + recurrence-editor build rules via the helper.
- demo fixture cleaned; unit test asserts no skip/rscale.
Closes#805.