RS Release Notes

Problem
Sentry [NODE-EXPRESS-3B](https://rent-solutions.sentry.io/issues/NODE-EXPRESS-3B): GET /api/leasing-properties 500s with invalid input syntax for type uuid: "undefined".

Stale or mangled URLs (e.g. ?leasingAgentId=undefined) cause the shared useFilterParams hook to return the literal string "undefined". It's truthy, so callers (e.g. RentalList) forward it as an API filter, and it lands in a UUID column → Postgres 500.

Fix
In useFilterParams, treat literal "undefined"/"null" URL values as absent and fall back to the default. Fixing it at this shared source covers every page that reads URL filters (rentals, showings, applications, feedback, etc.), not just the one endpoint.

Problem

Users hit Failed to update unit in Appfolio: Only one of the following parameters is permitted: MarketRent (recommended), ListedRent, or ListedMarketRent when saving the Property Profile (reported by Joe Nunez on 2411 W Fig St Unit 1).

Root cause

mapUnitDataToAppfolioFormat (shared by unit create and update) always put both rent keys in the PATCH payload:

ListedRent: unitData.listedRent || null,
ListedMarketRent: unitData.marketRent || null,

AppFolio's unit endpoint permits only one rent parameter per request. Even when a value is null, the key is still present, so AppFolio rejected every unit save that ran through this mapper.

Fix

Send a single rent parameter, matching the known-good price-change sync path (priceHistoryService / leasingPropertyService):

appfolioUnitPayload.ListedRent = unitData.listedRent || null;
appfolioUnitPayload.AdvertiseUsingListedMarketRent = true;

The rest of the unit payload (bedrooms, description, marketing, deposit, etc.) is unchanged, so those fields keep syncing to AppFolio. All three AppFolio unit-rent write sites now use an identical rent payload. No other AppFolio write (owners/tenants/properties/groups) carries rent params.

• Removes the update() call in ensureTwimlApp that was overwriting the TwiML app voice URL on every fresh process start
• Replaces it with a read-only fetch() that only validates the SID exists
• Renames cachedTwimlAppSid to validatedTwimlAppSid to reflect the actual behaviour
• Voice URL is now managed exclusively via the Twilio console — no environment can overwrite it at runtime

Problem

Agents (Jennifer & Roberto Verbel) reported no text/email alerts for new leads — visible in Edge but no notification.

Root cause (confirmed vs prod): the only "new lead" alert (new-communication-from-profile) fires only when an inbound email/SMS is matched to a lead (sender == lead's stored email). Portal leads (Zillow/Realtor/etc.) arrive from masked relay addresses that never match, so brand-new leads were never alerted. Prod (1 company, 14d): 665 leads (465 Zillow), 11,678 inbound emails, only 78 matched. Roberto 0/51 alerted, Jennifer 1/63. Not a regression — structural.

Fix

Notify the assigned leasing agent directly on tenant lead creation/assignment, decoupled from email matching. Additive — existing reply alert kept.

• New new-tenant-lead-assigned template (email/sms/in-app).
• New leadAssignmentNotificationService.notifyTenantLeadAssigned helper (fire-and-forget, respects UserNotificationPreference).
• Creation: fired from afterCreate via transaction.afterCommit — covers every creation path (manual, portal/webhook, bulk).
• Reassignment: updateTenantLead + batchReassignTenantLeads alert the new agent post-commit.

Owner leads: unchanged. They already have a single robust assignment notification (owner-lead-agent-assigned from updateOwnerLead, with proper role labels). No duplicate mechanism added.

• SlideOutPanel (leads detail, course panels, etc.) now closes the EdgePhone on open, guarded so it won't close mid-call
• AdminPortalLayout enforces mutual exclusion between the phone, AI chat, and CallQ edge panels — opening any one closes the others
• Uses a useRef prev/curr diff instead of three separate single-dep useEffect hooks, which had a closure-stale cascade that caused the chat panel to immediately close after opening when the phone was already open

• ensureTwimlApp had a fallback that searched for a TwiML app by friendly name (RentSolution Webphone) when the configured SID failed to update
• On a shared Twilio account, this silently overwrote the production app's voice URL with the staging WEBHOOK_BASE every time a staging user hit the token endpoint with an invalid/mismatched SID
• Removed the fallback entirely — TWILIO_TWIML_APP_SID is now required; a missing or unreachable SID logs an error and returns null instead of auto-discovering and clobbering whatever app it finds

Problem

In Lease → Rentals → Property Profile (also reachable via Property Marketing), editing any field (e.g. Pet Policy) and hitting Save silently did nothing in staging/prod — the card exited edit mode and the field reverted, with no error shown.

Root cause (verified via real browser E2E)
The backend *does* return the error (e.g. an AppFolio sync rejection surfaces as a 400 with a real message), and the axios interceptor *does* call showErrorToast. But showErrorToast in @utils/toast is gated behind VITE_NODE_ENV === "local", so it's a no-op in every non-local environment. The error was generated and then thrown away before the user could see it — looking like a silent failure.

(Reproduced by forcing the 400 on the unit PUT and observing zero feedback.)

Fix (scoped, inline)

All in PropertyProfileCard.jsx:
• On save failure, surface the actual backend message inline in a red banner at the top of the card.
• Stay in edit mode so the user keeps their input and can retry.
• Guard the form-hydration effect with if (isEditing) return; so an in-flight refetch no longer clobbers unsaved input mid-edit.
• Error clears on Edit, Cancel, and a successful Save.

What
When creating a process from the New Process card, the role selectors (Leasing Agent, Property Manager, Leasing Manager, Assistant PM) now pre-fill from the owner lead linked to the selected profile, instead of starting empty.

How
A new useEffect watches profilePreview.suggestedRoles (added to the GET /api/process/profile-preview response on the backend) and fills the role assignment selectors. It only fills slots the user has not already set, so manual choices are never overridden. No effect in edit mode.

Pairs with backend PR that adds suggestedRoles to the profile-preview response.

Problem
When a process was created from an owner lead, the role assignments (Leasing Agent, Property Manager, Leasing Manager, Assistant PM) were not carried over — the new process started with empty roles. This affected both:
1. Automatic spawns — createProcess automation tasks (e.g. owner-lead onboarding spawning *Property Marketing* / *Property Onboarding*).
2. Manual creation — the New Process card had no way to pull the owner lead's people.

Changes
automationService.executeCreateProcessTask — before creating the child process, map the source process's processRoles onto the target template's role slots by roleId (a shared Role entity reused across templates) and copy the assigned userId. Roles unique to the source are dropped; roles unique to the target stay unassigned. This also avoids createProcess#detectRoleKeys throwing on a roleId the target template doesn't define.

processService.getProfilePreview — new helper getSuggestedRolesFromOwnerLead returns suggestedRoles derived from the most-recent owner lead linked to the selected owner (read from the owner lead's denormalized role columns, not its processRoles JSONB which can be the legacy {}). getProfilePreview now includes suggestedRoles so the frontend New Process card can pre-fill role selectors. linkedProfiles output is unchanged.

Pairs with frontend PR #2605.

What

Adds a clear (✕) icon to the editable fields in the New Process card so a selection can be reset:

• Template
• Process Owner
• Select property / unit / owner (searchable dropdown)
• Tenant Lead
• Role assignment selects (Property Manager, Leasing Manager, etc.)

Disabled preview fields (Bedrooms, Bathrooms, Address, Phone, Email…) are intentionally left untouched.

How

Reuses the existing showClearIcon prop already implemented on Field/Input and Dropdown — no new components or custom styling. The icon only renders when a value is set and the field isn't disabled; clicking it fires the field's existing onChange with an empty value.

Problem
When creating a new owner lead, the Lead Owner was being auto-assigned into the role_1 process-role slot. On the company template whose role_1 is the Leasing Manager role, this dropped the creating user into the Leasing Manager slot while Leasing Agent / Property Manager stayed empty.

This surfaced in the stage's assign-roles task (and any role_1.* / role-name merge fields), which read process.processRoles directly. (The owner-lead PreQualify section reads the leasingManagerId FK — which stays null — so it correctly showed blank; that mismatch is what made this confusing.)

Root cause (confirmed against prod data)
createOwnerLead injected { key: 'role_1', roleId, userId: leadOwner } into processRoles at creation. Prod leads in early stages (New, Made Contact, Active Nurturing, Sent Agreement) already carried role_1 = Leasing Manager = lead owner — proving it's set at creation, not at the stage move.

Fix
Remove the role_1 auto-assignment. Role people-assignments now start empty and are set deliberately. The Lead Owner is unaffected — it's still persisted via assignedToUserId and process.processOwner, independent of any role slot.

Scope
• Only affects new owner leads going forward. No backfill of existing leads (per request).
• Templates where role_1 was used as a generic owner slot will now show that role blank by default (intended).

LeadList read viewMode straight from the view URL param. The Rentals page uses a view=Badge value that can persist in the URL when moving between sections (also reachable via bookmarks/back-button). On the Lead Pipeline, Badge matches neither the Pipeline nor List toggle option, so the render fell to the empty-DataList branch (whose query is disabled) — leaving the board blank with no toggle selected.

Fix: validate the param so any unrecogni

Problem
A spam email arrived via the Gmail webhook with a ~700-char subject. Both EmailThread.subject and EmailMessage.subject are varchar(255), so the insert in EmailThread.findOrCreateByProvider threw:

SequelizeDatabaseError: value too long for type character varying(255)

This freezes the Gmail webhook's historyId in a retry loop — same failure class as the previously fixed NODE-EXPRESS-13/27.

Sentry: NODE-EXPRESS-3A.

Fix
• Add a beforeSave hook on both EmailThread and EmailMessage that caps subject at 255 chars on every write path (create, findOrCreate, and the update calls in saveMessages). Both are fixed because the thread insert failed first — fixing only the thread would just move the same error to the subsequent message insert.
• In saveMessages, compare the incoming subject against its truncated form so an overlong subject no longer looks 'changed' and thrash a redundant thread update on every sync.

Problem
All SideCards (PropertyDetailCard, TaskDetailCard, LeadDetailCard, etc.) render through the shared SlideOutPanel → Modal. The Modal backdrop is z-50, which sits above the top navbar (header z-40, nav-tabs z-30). The navbar's hover dropdown menus are confined to the navbar's own stacking context, so when a SideCard was open the menu dropdowns rendered behind it — the panel overflowed the menu hover states.

SlideOutPanel already offsets its backdrop to start below the navbar (top: navHeight), signalling the navbar should stay above the panel; only the z-index was missing.

Fix
Drop the SideCard backdrop to !z-[25] — above page content (z-20) and below the navbar (z-30/z-40) — so navbar menu dropdowns render on top. One-line change in the root SlideOutPanel, so every SideCard is covered.

Problem
On the tenant lead detail page, the Lead Info → Comment box renders two scrollbars on Windows but only one on macOS (see reported screenshot).

Root cause
The Comment box had two nested scroll containers:
• The InnerBox body wrapper — min-h-0 overflow-y-auto
• The textarea itself — max-h-16 overflow-y-auto

macOS uses *overlay* scrollbars (hidden until hover, zero layout width), so the redundant pair looks like one. Windows uses *classic* scrollbars that always occupy layout space, so both render side by side.

Fix
Disable the InnerBox body wrapper's scroll for this single instance via bodyClassName="!overflow-y-visible", leaving the textarea as the sole scroll owner. Scoped to this instance only — no other InnerBox usage is affected.

Problem (ENG-545)

Individual applications get stuck on "In Progress" forever when the applicant first applies solo and is later merged into a co-applicant's application in Findigs.

Findigs fires its decision webhooks (groups.approved / groups.declined) on the surviving group only, and deletes the orphaned solo group (its live fetch 404s). So our solo Application never receives a terminal event, and refreshApplicationFindigsCore has no removal logic — the row sits at in-progress indefinitely and clutters the In Progress toteboard.

Confirmed against prod: 2 affected apps, each sharing an applicant email with an approved application in a different group; the solo groups 404 in Findigs (deleted on merge).

Fix — cancel the merged-away solo app, recording the group's outcome

When an application reaches a decision (setStatusApproved / setStatusDeclined), we detect orphaned solo siblings and cancel them, recording the surviving group's outcome (Approved/Denied) in the cancel note:

• supersedeMergedSiblingApplicationsCore (dependency-injected, unit-testable like refreshApplicationFindigsCore) finds open apps in the same company sharing an applicant email but in a different Findigs group.
• It re-confirms the merge live before acting — only proceeds if the shared applicant is gone from the sibling's group, or the group 404s (deleted on merge). Avoids false-positives where someone legitimately holds two open applications.
• _applyMergedSiblingOutcome cancels via the existing cancelApplication (history log +…

Problem
When a tenant lead is created but its company has no default tenantLead process template, afterCreate silently skips process creation. The lead ends up with processId = null, never resolves to an active stage, and is invisible in the active pipeline / leads list (only shows under "Show Inactives"). This was logged locally only and went unnoticed.

Fix
Add Sentry.captureMessage (level warning) in the no-template branch of TenantLead.afterCreate, with the tenantLeadId + companyId, so process-less leads are caught.

Scope note
This guards the missing-template path. Leads inserted via a bulk path that bypasses the Sequelize hook (raw SQL / bulkCreate) never run afterCreate at all, so they won't be caught here — those must go through createTenantLead / upsertTenantLead (hooks on). Surfacing that class is a separate follow-up (implementing the tenant-lead import branch, currently a TODO stub in leadImportHandler).

What
Wires up the (previously non-functional) + button in the Applications list header to create an application manually for an existing tenant lead.

The + IconButton has existed since the page was built but never had an onClick, and createApplicationMutation was never invoked anywhere — so manual application creation was impossible in the UI.

Why
Companies that don't use Findigs (e.g. AppFolio guest-card workflows) had no way to start an application from the UI — the lead "Send App" flow only sends a Findigs link. POST /applications only needs a tenantLeadId (the lead already carries property/unit/company context), so a lead picker is sufficient.

How
• ApplicationListNewCard.jsx (new): a CardWindow with a searchable Dropdown (server-side onSearch) to pick a tenant lead, then createApplicationMutation → navigate to the new application.
• Eligibility: only active-status tenant leads are selectable (status: 'active').
• useTenantLeads.js: extended useTenantLeadSearch to apply defaultFilters to the search branch too (eligibility applies while searching, not just the initial list). No other consumers.
• ApplicationList.jsx: import the card, isCreateAppOpen state, wire the existing + onClick, render the card. Existing canCreate() && hasApplicationListFullAccess gating preserved.

Problem

A manually-added tenant lead on Ellis got stuck on infinite loading. The lead's process had processRoles stored as {} (a JSON object) instead of [] (an array). Backend readers iterate it (for…of / .find / spread), so they threw processRoles is not iterable, 500ing GET /instances/:processId/tasks and /tasks/:id/instruction-details → the detail page's tasks panel span forever.

Root cause

Process.processRoles is documented and consumed as an array, but the column defaultValue was {}. The tenant-lead afterCreate hook builds the roles array from the lead's assigned Leasing Agent/Manager/PM, then did:

processRoles: processRoles.length > 0 ? processRoles : undefined

When a lead has no assigned roles, it passed undefined, so Sequelize wrote the {} default. Companies that assign agents on their listings always produced a non-empty array and never hit this; companies/properties with no roles assigned (e.g. Ellis manual leads) did.

Fix

• models/processModel.js — column default {} → [] (the real fix).
• models/leasing/tenantLeadModel.js & services/leasing/tenantLeadService.js — always pass the roles array (drop the : undefined) so the create/update→create paths never fall back to the column default.
• migration — normalize existing non-array processRoles to [] (jsonb_typeof <> 'array'), idempotent, lossless …

• Adds the EdgePhone webphone panel with dialpad, contacts, recents, voicemail, and favorites
• Fixes merge call ownership, caller ID display, conference label, and voicemail paste
• Fixes handshake modal to open for personal-phone-only users and passes phoneKey correctly
• Replaces composite icon with dedicated EdgePhoneIcon SVG

• Adds backend webphone support including Twilio device integration and pending transfers service
• Fixes heldCallLogId threading through hold→merge chain for correct ownership resolution
• Fixes phone2 selection, callLogId creation, and pre-write race condition on handshake

Problem
After the importer started updating existing records (BE PRs #2299/#2300), the result screen still only rendered created/skipped/failed. A re-import of an existing portfolio is update-heavy — almost nothing is "created" — so the screen showed "0 created" + red bars even when thousands of rows updated successfully, making a healthy sync look like a total failure. (This is exactly what made a real Ellis import *look* failed when only 5 of ~3,720 rows actually failed.)

Change
Surface updated everywhere the result is shown:
• Per-entity tiles: now " synced" = created + updated (both live during processing and on completion) — never misleadingly 0.
• Per-entity bar chart: new Updated series (rsos-blue #0090CD).
• Overall-outcome donut: new Updated slice.
• Recent-imports "Result" column: " created · updated".
• Additive-import description: corrected — existing records are *updated to match the upload* (matched by AppFolio id), not skipped.

The undo confirmation still uses created only (undo removes only created records — unchanged).

Problem
A real Ellis import (#2299 already merged) failed one property with:

duplicate key value violates unique constraint "properties_appfolio_uuid_company_unique"
Key ("appfolioId","companyId")=(24897e1a-be39-11ef-..., Ellis) already exists.

The property already existed in Edge under a slightly different name string, so the importer's name-only dedup missed it, tried to CREATE it, and hit the (appfolioId, companyId) unique constraint — failing that row and cascading "No property" to its unit + 2 tenants. The lone Peralta De Leon tenant failure was the same bug on tenants (dup Tenant Integration ID).

Net effect on screen: import showed red "failed" bars even though ~3,715 records updated fine — only these 5 rows died.

Fix
Match existing owners / properties / units / tenants by their AppFolio integration id as a fallback to the name/email/key match. A record whose stored name drifted from the export now routes to the update path instead of a doomed create. Plus:
• When a property/unit is matched by appfolioId (name differs from the CSV), register the CSV name in the in-run lookup maps so child rows referencing it by the new name still resolve.
• Integration ids are registered after each create so a duplicate id within one file can't create twice.

Vendors carry no integration id, so they're unchanged.

Problem
The Directory Import was create-only. Existing owners/properties/units/tenants/vendors were dedup-matched and skipped with zero writes, so re-uploading a fresh AppFolio export couldn't fix drifted data.

Concretely (found while diagnosing Ellis HomeSource showing 5 Rentals listings vs 7 on their AppFolio website): the company has no AppFolio Report API credentials, so the nightly unit-report sync fails and units.postedToInternet is frozen. 4 currently-posted units sit at postedToInternet=false with inactive leasing properties → off the Rentals list. Re-running the import did nothing because those units already existed and were skipped.

Change
Existing records are now reconciled from the CSV instead of skipped:

• Units — update all scalar fields + postedToInternet/postedToWebsite, and route the unit into the activate list (Posted=Yes) or a new deactivate list (Posted=No), bringing the leasing property's active/inactive status back in line with AppFolio. A posted existing unit with no leasing property gets one created.
• Properties / owners / tenants / vendors — scalar field reconcile via direct Model.update (no per-row service hooks, AppFolio push, or workflow events — same reason the importer already bypasses the create services under bulk load). Contact child rows (Email/PhoneNumber) are left untouched to avoid duplicates.
• Activation/deactivation only run when the unit CSV actually carries the Posted To Internet column, so a stripped export never wipes listings.
• Stats gain per-type updated counters and le…