A Salesforce Lightning Web Component implementation of forceCalendar, with a scheduling interface over the standard Event sObject. Lightning Web Security must be enabled: Salesforce does not support third-party custom elements under Lightning Locker. See Salesforce custom-element support.
This repository contains the Salesforce integration and build tooling. The calendar engine lives in @forcecalendar/core and the Web Components in @forcecalendar/interface; this repo connects them to Apex and bundles them into a deployable Salesforce DX source tree.
The production LWC was verified against actual Salesforce Event records using only disposable synthetic fixtures: create, read, edit, cancellation, confirmed delete, refresh/navigation persistence, and inclusive all-day dates. All test records were removed afterward.
Interface 1.9 adds existing-event details, title/location/date editing and confirmed deletion. Native recurring Salesforce Events remain read-only here; manage their series or occurrences in Salesforce Calendar. Restricted-user behavior is covered by isolated Apex tests; an actual restricted-user Lightning session has not been tested. See verification scope.
No npm required — everything is pre-bundled.
Verified beta 0.3.0.1: Install in a sandbox or install in a Developer Edition org. This unlocked beta passed a clean install and all 32 Apex test methods, with 98% package coverage. It has not been promoted for production installation. Review permissions before assigning access.
For a source deployment:
- Download
forcecalendar-salesforce-dist.zipfrom the latest release and unzip it. - Deploy with the Salesforce CLI:
cd dist
sf project deploy start --target-org your-org-alias(or run the generated deploy.sh / deploy.bat)
- Drag the Force Calendar component onto any App, Record, or Home page in Lightning App Builder. Design attributes:
currentView(month/week/day),height,readOnly.
Deploy the LWC, Apex controller and static resource together. The updated LWC requires the controller's date-aware createCalendarEvent and updateCalendarEvent methods and the interface snapshot API. Legacy Apex create/update entry points remain available.
Choose one optional permission set and assign it only to intended users:
- ForceCalendar Access: Apex controller access only, for orgs managing their own activity permissions.
- ForceCalendar Reader: controller access, Access Activities, and read access to the five permissionable fields used by the component.
- ForceCalendar Editor: Reader access plus Edit Events and edit access to those fields. Edit Events permits create/update/delete subject to Salesforce sharing.
No permission set is assigned automatically. These sets do not grant related Account/Contact/Lead access, Edit Tasks, View All or Modify All. Permission sets are additive: Reader cannot revoke write rights a user already has. Access Activities covers activities beyond this calendar; Salesforce shares Description/WhoId/WhatId field permissions with Task. Subject/StartDateTime/EndDateTime do not have independent configurable FLS. See permission setup and scope before assignment.
Creates on Contact/Lead pages use WhoId; supported related-record pages use WhatId. Related-record pages require access to that object and record; inaccessible or unsupported contexts fail closed.
readOnly disables the interface's editing and dragging controls while preserving navigation and selection. It also blocks the LWC's save callbacks and public addEvent method. This UI setting is not a security boundary; Salesforce permissions are enforced independently by Apex.
| Artifact | Purpose |
|---|---|
staticresources/forcecalendar.js |
Single-file bundle of @forcecalendar/interface + @forcecalendar/core |
lwc/forceCalendar |
Production component — loads the bundle, renders <forcecal-main>, wires events to Apex |
lwc/forceCalendarDemo |
Standalone demo with generated sample events (no data access) |
classes/ForceCalendarController |
Apex data layer over the standard Event sObject (sharing, user-mode reads and writes with CRUD/FLS enforcement) |
permissionsets/ForceCalendarAccess, ForceCalendarReader, ForceCalendarEditor |
Optional controller-only, read, and edit permissions; no automatic assignment or sharing bypass |
Data flow: Event sObject → Apex → LWC → <forcecal-main> Web Component, with user actions (create/update/delete, navigation) flowing back the same way.
All-day events use inclusive civil dates: Start date October 5 and Last day October 7 covers three days; a same-day event is valid. The adapter maps these dates explicitly to Salesforce’s native UTC-date fields without shifting them by the browser timezone. Timed events continue to use actual instants. Existing records display their stored dates; there is no automatic historical-date repair.
Fetched events use the interface's setEvents snapshot API. Loading, refreshing and changing the visible range never issue Apex create/update/delete calls. Date queries include overlapping events, even when they begin before or finish after the requested window. The range end is inclusive (the LWC sends 23:59:59.999); events starting exactly at that end are included, while events ending exactly at the range start are excluded.
npm ci
cd src && npm ci && cd ..
npm run build # bundles the static resource and assembles dist/
npm test # builds, compiles the LWC and tests against the real bundleThe local Jest suite mocks Apex transport, not the calendar. It covers snapshot safety, CRUD command forwarding, Location, record context, cold loading, reconnects, multiple instances and read-only persistence guards. It does not execute Apex or prove Lightning Web Security behavior in an org.
The pinned bundle uses core 2.5.6 and interface 1.9.0. Its read-only UI integration regression runs automatically. For an older local release candidate, FORCECALENDAR_READONLY_UI=1 explicitly enables the same check against that prebuilt bundle.
After an authorized deployment, run ForceCalendarControllerTest in the target org and check restricted users, record-page creation and refresh/navigation in Lightning before promoting the package. Apex tests require an authenticated Salesforce org and are not run by npm test.
See the organization-wide contributing guide and security policy.