Tags: box/box-ui-elements
Tags
fix(activity-feed-v2): apply a comment range after the preview width … …settles (#4879) * fix(activity-feed-v2): apply a comment range after the preview width settles * test(activity-feed-v2): move the preview width helper into testUtils * test(activity-feed-v2): assert dropped ranges after the preview width settles * fix(activity-feed-v2): apply a comment range after the preview size settles * test(activity-feed-v2): rename the preview settle helper for the size wait
feat(feed): send enable_rich_text on feed reads and writes (#4823) * feat(feed): request wrapping markdown on flag-on GETs Flag-off and older clients omit the key so those reads still unwrap. Never send false. * fix(feed): send rich text on annotation thread GET Opening a thread re-fetched without the flag, so a flag-on feed could return wrapped markdown while the thread GET stayed unwrapped. Legacy non-reply comments stay unwrapped; that API has no param. * fix(api): always send enable_rich_text on GETs An omitted param is not an explicit strip. Flag-off callers must still send false so the API strips rich text. * test(feed): lock rich text on reply GETs Default-off tests still pass if a caller stops forwarding the flag on reply and active-comment GETs. * chore(deps): bump @box/threaded-annotations to 4.14.0 Picks up the mid-word bold/italic/underline input and paste rules in the v2 message editor shipped in threaded-annotations 4.14.0. No API or contract changes, so no source updates are needed here. * refactor(activity-sidebar): read rich-text flag through one getter The activityFeed.richText.enabled lookup was repeated at five call sites. A single getIsRichTextEnabled getter keeps the flag name in one place, so the feed GETs and the V2 render path cannot drift apart. * refactor(feed): drop cached rich-text flag field The shouldEnableRichText field was only set inside feedItems, after the cached-items early return, and the fetch methods fell back to it. A fetch called before feedItems silently read a stale false. Every caller already passes the flag explicitly, so the fetch methods now default the param to false and the field is gone. * test(api): cover rich-text flag-on path on remaining GETs getComments, getCommentReplies, getAnnotationReplies, and getActivities only asserted the flag-off request. Without a flag-on case, a refactor that dropped enable_rich_text from those requests would still pass. * feat(feed): send enable_rich_text on feed writes The sidebar renders create, reply, edit and resolve responses from the cache without refetching. Once the backend strips wrapping markdown unless enable_rich_text is set, those responses would show plain text until the next full read, so writes send the same flag as reads. ThreadedComments and Annotations write methods take shouldEnableRichText and send it as a query param; Feed, ActivitySidebar, useAnnotationAPI and useRepliesAPI pass it through. Test argument updates only; one stray argument in the createThreadedComment Feed test was shifting callbacks. * refactor(api): always pass params on getAnnotation enable_rich_text is always set, so the Object.keys(params).length guard was always true. * chore(deps): refresh yarn.lock Local yarn install split the string-width, strip-ansi and wrap-ansi entries out from their -cjs npm aliases. Versions and integrity hashes are unchanged; only the lockfile layout differs. * test(feed): cover enable_rich_text=true on feed writes Existing tests only asserted enable_rich_text=false on writes. The flag is coerced with Boolean() and defaulted to false, so any layer that dropped it would still pass them. Add true cases for each write at every layer: sidebar handlers, annotation-thread hooks, Feed, and the Annotations and ThreadedComments APIs. Also assert that Base.makeRequest and Xhr post/put forward params alongside the body, since writes put enable_rich_text in the query string through that path. --------- Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
feat(activity-feed-v2): open Activity when the viewer drag-creates a … …comment range (#4864) * feat(activity-feed-v2): open Activity when the viewer drag-creates a comment range Adopt comment_range_compose from sidebar chrome so a collapsed feed still opens, pins the range, and focuses the editor without echoing a draft. * fix(audio): address coderabbit comments * fix(audio): address PR comments round 1 * fix(flow): fix flow lint error * chore(ci): trigger CI
fix(content-sidebar): Bold details section headers (#4861) * fix(content-sidebar): Bold details section headers Render Classification, Content Insights, and File Properties with bodyDefaultBold. Convert SidebarClassification and SidebarSection to TypeScript and cover them with React Testing Library. * test(content-sidebar): Update SidebarSection enzyme snapshots Enzyme shallow no longer records class default props after the function component conversion. The runtime defaults are unchanged. * fix(content-sidebar): Bold the Access Stats section header Render Access Stats with bodyDefaultBold so it matches the other details section headers. --------- Co-authored-by: Jackie Jou <jackiejou@users.noreply.github.com>
feat(activity-feed-v2): uncheck timestamp toggle when viewer dismisse… …s range draft (#4841) When the user clicks the waveform outside an open comment range, the viewer emits comment_range_draft_dismiss. Treat that as toggle-off so the checkbox, pinned range, and draft handles stay in sync. Co-authored-by: Cursor <cursoragent@cursor.com> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
PreviousNext