Báo động khẩn cấp

Xác nhận một sự cố khẩn cấp đang mở thay mặt người dùng: ghi nhận rằng họ đang phản hồi và có thể dừng việc báo động leo thang tiếp. Chỉ có thể xác nhận các sự cố đang mở.

Luôn xác nhận trước. Gọi mà không có confirm để lấy sự cố, cho người dùng biết họ đang xác nhận điều gì, và chỉ gọi lại với confirm: true sau khi họ đồng ý.

Trong một workflow, hoặc từ một Agent, thao tác này chỉ hoạt động khi kế hoạch ứng phó của cơ sở cho phép workflow xác nhận, giải quyết và kích hoạt báo động. Để đóng sự cố, hãy dùng duress_resolve_incident.

Đọc các nút báo động tại một cơ sở: trạng thái (pin, lần nhận tín hiệu gần nhất, lần kiểm tra gần nhất), hồ sơ đầy đủ (nhãn, phòng, vùng, vị trí lắp đặt, camera, cửa và màn hình được liên kết, cảnh báo đã tắt tiếng, tình trạng giám sát), những gì có thể liên kết, các màn hình chuyển tiếp lượt nhấn, và bài kiểm tra thiết lập của nút mới được thêm.

Pin: low là 30% trở xuống (sắp cần thay), critical là 20% trở xuống (cần thay ngay). Giá trị battery và lastSeenAt null nghĩa là chưa có màn hình nào nhận được tín hiệu của nút. Thời gian theo định dạng ISO.

Các hành động:

• status: Trạng thái nút. Mỗi nút kèm vùng, phòng, pin, thời điểm màn hình nhận được tín hiệu gần nhất và thời điểm kiểm tra gần nhất. "Các nút báo động có đang hoạt động không?", "Nút nào cần thay pin?"
• list: Hồ sơ nút. Hồ sơ đầy đủ của mỗi nút: những gì duress_buttons_write update thay đổi, cùng tín hiệu, các màn hình đã nhận được tín hiệu trong ngày qua, tình trạng giám sát và bài kiểm tra thiết lập đang chờ.
• link_options: Tùy chọn liên kết. Các camera, cửa, màn hình và vùng truy cập của cơ sở mà một nút có thể liên kết (ID cho duress_buttons_write update).
• receivers: Bộ thu của nút. Các màn hình hiển thị tại cơ sở nhận tín hiệu nút và chuyển tiếp lượt nhấn, và mỗi màn hình có trực tuyến hay không. ready là false khi không có gì nhận được tín hiệu nút.
• setup_test: Kiểm tra thiết lập. Bài kiểm tra thiết lập của nút mới được thêm: waiting (lượt nhấn đầu tiên chỉ là kiểm tra), received, expired, ended hoặc none, và đã có màn hình nào nhận được tín hiệu của nút kể từ khi thêm hay chưa. Cần deviceSerialNumber.

Thay đổi các nút báo động tại một cơ sở: thêm nút mới, hồ sơ của nút (nhãn, phòng, vùng, vị trí lắp đặt, ghi chú, camera, cửa, màn hình và vùng truy cập được liên kết, cảnh báo thiết bị đã tắt tiếng), làm cho một nút phát tiếng bíp để nhân viên tìm thấy, kết thúc bài kiểm tra thiết lập của nút mới để nút bắt đầu hoạt động, và gỡ một nút.

Các trường bị bỏ qua trong update giữ nguyên giá trị; null sẽ xóa giá trị. Đọc hồ sơ hiện tại bằng duress_buttons_read list.

Các hành động:

• update: Cập nhật nút. Lưu hồ sơ của nút tại cơ sở mà nút được đăng ký (cần Duress Configuration tại đó). zone từ 001 đến 999 và là duy nhất tại cơ sở. alertsMutedUntil (ISO, tối đa 30 ngày tới) tắt tiếng cảnh báo pin và ngoại tuyến của nút. Cần deviceSerialNumber.
• locate: Làm cho nút phát tiếng bíp. Nút sẽ phát tiếng bíp và nhấp nháy trong 30 giây để nhân viên tìm thấy, ví dụ một nút liên tục báo pin yếu. Một màn hình gần nút sẽ gửi lệnh, vì vậy nút phải nằm trong phạm vi của một màn hình. Không thực hiện được khi nút có báo động đang mở. Cần deviceSerialNumber.
• go_live: Đưa nút mới vào hoạt động. Kết thúc ngay bài kiểm tra thiết lập của nút mới được thêm, để lượt nhấn tiếp theo là báo động thật. Hãy kiểm tra duress_buttons_read setup_test trước. Cần Quản lý thiết bị hoặc Duress Configuration tại cơ sở. Cần deviceSerialNumber. Yêu cầu xác nhận.
• remove: Gỡ nút. Hủy ghép nối nút khỏi cơ sở và xóa hồ sơ của nút, giải phóng vùng của nút. Không thực hiện được khi nút có báo động đang mở. Cần Quản lý thiết bị tại cơ sở. Cần deviceSerialNumber. Yêu cầu xác nhận.
• add: Thêm nút. Đăng ký một nút báo động mới tại cơ sở bằng số sê-ri in trên nút. Theo mặc định, lượt nhấn đầu tiên trong 30 phút tới chỉ là kiểm tra (setupTest). Cơ sở cần một màn hình đã bật Duress alarm monitoring hoặc một IoT Gateway. Cần Quản lý thiết bị tại cơ sở. Cần deviceSerialNumber. Yêu cầu xác nhận.

Kết thúc ngay bài kiểm tra báo động đang chạy tại một cơ sở, để lượt nhấn tiếp theo là báo động thật. Kết quả sẽ có sau khoảng 10 phút, như với mọi bài kiểm tra.

Đọc các sự cố báo động khẩn cấp (nhân viên nhấn nút báo động, hoặc một workflow kích hoạt báo động): danh sách, dòng thời gian và lượt gửi thông báo của một sự cố, báo cáo phân tích sau sự cố, và đoạn phim camera giám sát quanh thời điểm báo động.

Trạng thái: open (chưa ai xác nhận), acknowledged (đã có người phản hồi), resolved (đã đóng, kèm kết quả xử lý: genuine, false_alarm, test hoặc unknown). active nghĩa là open hoặc acknowledged. Sự cố kiểm tra (isTest) đến từ các bài kiểm tra nút; testType 'unplanned' là báo động được kích hoạt như thật nhưng người phản hồi đã giải quyết như một bài kiểm tra.

Trạng thái gửi: sent, acknowledged (người nhận đã xác nhận), failed (xem error), shadow (chạy thử, không gửi gì). Các lượt gửi đến trung tâm giám sát cũng được tổng hợp trong monitoringCentre. Kết quả nêu tên người nhưng không bao giờ bao gồm số điện thoại hoặc địa chỉ email. Thời gian theo định dạng ISO.

Các hành động:

• list: Liệt kê sự cố. Mới nhất trước. scope: facility (mặc định; cơ sở được chỉ định hoặc đang kết nối) hoặc organisation (mọi cơ sở trong tổ chức mà bạn xem được; mặc định là tổ chức của cơ sở).
• get: Lấy một sự cố. Trạng thái, các nút đã nhấn, dòng thời gian (lượt nhấn, leo thang, xác nhận, ghi chú) và mọi lần gửi thông báo hoặc gửi đến trung tâm giám sát kèm kết quả. Cần incidentId.
• report: Báo cáo sự cố. Dùng cho phân tích sau sự cố: sự cố, số giây đến khi xác nhận và giải quyết, các bước đã đạt, mọi mục trong dòng thời gian, những gì đã gửi theo từng kênh và những gì thất bại, và đoạn phim có được giữ lại hay không. Kết hợp với duress_incidents_write add_note để đưa phân tích sau sự cố vào sự cố. Cần incidentId.
• footage_previews: Đoạn phim báo động. Mỗi camera trong đoạn phim báo động: trạng thái, số khung hình và số đoạn clip, các clip đã tải lên, và khung hình gần thời điểm nhấn nhất (posterSeconds). Với cameraId, chỉ camera đó kèm thời điểm Unix tính bằng giây của mọi khung hình (frameSeconds). Cần camera giám sát tại cơ sở. Cần incidentId.
• footage_frame: Khung hình của đoạn phim báo động. Một khung hình timelapse từ đoạn phim báo động, trả về dưới dạng hình ảnh: bản sao đã giữ lại khi đoạn phim đã được giữ, nếu không thì khung hình trực tiếp trong khoảng thời gian báo động. seconds là một giá trị posterSeconds hoặc frameSeconds từ footage_previews. Cần incidentId, cameraId, seconds.

Thay đổi một sự cố khẩn cấp mà không tác động đến chính báo động: đặt tên, thêm ghi chú của nhân viên, và giữ lại hoặc giải phóng đoạn phim camera giám sát quanh sự cố. Không ai nhận cảnh báo. Để xác nhận, giải quyết hoặc thông báo cho người phản hồi, hãy dùng duress_acknowledge_incident, duress_resolve_incident hoặc duress_post_update.

Các hành động:

• rename: Đặt tên sự cố. Đặt tên cho sự cố để dễ tìm sau này, ví dụ "Khách hung hăng tại quầy phía trước". Tên trống hoặc null sẽ xóa tên. Tên hiển thị trong bảng điều khiển Duress và báo cáo. Cần incidentId.
• add_note: Thêm ghi chú. Thêm ghi chú vào dòng thời gian của sự cố, ví dụ người dùng đã phát hiện điều gì hoặc ai đã có mặt. Áp dụng ở mọi trạng thái; chỉ nhân viên thấy ghi chú và ghi chú không thay đổi sự cố. Hãy viết theo lời của người dùng và xác nhận câu chữ với họ trước. Cần incidentId, note.
• keep_footage: Giữ lại đoạn phim báo động. Giữ lại đoạn phim camera giám sát quanh một báo động thật đã được giải quyết để không bị xóa cùng các bản ghi thông thường, theo số phút và các camera trong kế hoạch ứng phó. Thực hiện sau vài phút, khi đã tải lên. Không áp dụng cho bài kiểm tra, báo động đang mở, hoặc đoạn phim đã được giữ lại hay đã giải phóng. Cần incidentId.
• release_footage: Giải phóng đoạn phim đã giữ lại. Từ bỏ đoạn phim đã giữ lại cho một báo động: các clip trở về thời gian lưu giữ thông thường và các khung hình đã giữ bị xóa, nên không thể xem lại sau khi các bản ghi thông thường hết hạn. Cần Duress Configuration tại cơ sở. Cần incidentId. Yêu cầu xác nhận.

Dỡ bỏ phong tỏa của một báo động khẩn cấp: các cửa đã bị khóa sẽ cho người vào trở lại. Hoạt động bất kể trạng thái của báo động.

Xác nhận trước. Gọi mà không có confirm để xem lệnh phong tỏa, thông báo cho người dùng, và gọi lại với confirm: true khi họ đồng ý.

Đăng thông tin cập nhật cho những người đang phản hồi một báo động khẩn cấp, ví dụ "Cảnh sát đang trên đường đến" hoặc "Đã an toàn, người đó đã rời đi". Thông tin xuất hiện trên trang báo động của họ và trong ứng dụng Duress, và với báo động thật, kế hoạch ứng phó cũng có thể gửi tin nhắn SMS cho tất cả những người đã nhận tin nhắn về báo động. Có thể đăng cập nhật cho đến 24 giờ sau khi báo động được giải quyết.

Xác nhận trước. Gọi mà không có confirm để kiểm tra sự cố, cho người dùng xem chính xác câu chữ, và gọi lại với confirm: true khi họ đồng ý. Với nội dung chỉ nhân viên nên thấy, hãy dùng duress_incidents_write add_note.

Kích hoạt một báo động khẩn cấp thật tại cơ sở, như thể có người nhấn nút: kế hoạch ứng phó sẽ chạy (mọi người được cảnh báo, tiếp theo là leo thang và nhắc nhở, các hành động ứng phó được thực hiện) và báo động ghi rõ rằng nó được kích hoạt bởi workflow này, kèm lý do.

• reason: điều đã xảy ra, ví dụ "Cửa thoát hiểm phía sau bị phá" (tối đa 200 ký tự).
• deviceSerialNumber: không bắt buộc. Một nút có vị trí sẽ được sử dụng; chỉ khi đó trung tâm giám sát mới được thông báo, kèm vùng của nút đó.

Chỉ dùng như một bước trong workflow, tại các cơ sở có kế hoạch ứng phó cho phép workflow xác nhận, giải quyết và kích hoạt báo động. Khi báo động của workflow này đang mở, công cụ sẽ không kích hoạt báo động khác mà trả về báo động đó.

Báo cáo tuân thủ Duress cho một cơ sở, thương hiệu hoặc tổ chức: thời gian phản hồi (P50/P95), sự cố theo kết quả xử lý và tỷ lệ báo động giả, mức độ bao phủ kiểm tra và các cơ sở quá hạn kiểm tra, thời gian hoạt động của nút, tỷ lệ gửi thành công đến trung tâm giám sát, và bản xuất theo từng sự cố. Ngoài ra là các cảnh báo chưa gửi được của báo động gần nhất tại một cơ sở.

Ngày tính theo giờ địa phương của cơ sở; khoảng thời gian trên 400 ngày sẽ được rút ngắn (range.capped). Sự cố thật và sự cố kiểm tra được tính riêng. Thời lượng tính bằng ms (p50Ms, p95Ms). Báo cáo thương hiệu chỉ bao gồm các cơ sở bạn có thể truy cập, trừ khi bạn có quyền truy cập toàn tổ chức (scope.restrictedToAccessibleFacilities).

Các hành động:

• overview: Tổng quan báo cáo Duress. Tổng số, xu hướng hằng tháng và các chỉ số theo tổ chức, theo thương hiệu và theo cơ sở (incidents, testCoverage, deviceUptime, deliveries). Các cơ sở được phân trang.
• compliance_summary: Tóm tắt tuân thủ Duress. Nội dung của bản PDF tuân thủ: mức độ bao phủ kiểm tra cùng các cơ sở quá hạn, thời gian hoạt động của nút, tỷ lệ gửi thành công, các bài kiểm tra gần đây (testHistory), và với mỗi cơ sở là bài kiểm tra, buổi diễn tập và báo động thật gần nhất kèm thời gian hoạt động của từng nút. Các cơ sở được phân trang.
• incident_export: Xuất sự cố Duress. Mỗi sự cố một dòng, cũ nhất trước, với các cột của bản xuất CSV: cơ sở, kiểm tra hay thật, trạng thái, kết quả xử lý, giờ địa phương, số giây đến khi xác nhận và giải quyết, người xác nhận và giải quyết, nút và số lượt gửi.
• delivery_problems: Cảnh báo báo động chưa gửi được. Báo động hoặc bài kiểm tra gần nhất của cơ sở (kèm toàn bộ khoảng thời gian kiểm tra) và các cảnh báo không bao giờ đến nơi, theo kênh. problems là null khi mọi thứ đã được gửi đến. Cần Duress hoặc Duress Configuration tại đó.

Giải quyết một sự cố khẩn cấp: đóng báo động, dừng leo thang và ghi nhận kết quả. Có thể giải quyết các sự cố đang mở và đã được xác nhận.

• disposition: genuine (trường hợp khẩn cấp thật), false_alarm, test hoặc unknown.
• note: điều đã xảy ra. Bắt buộc với báo động thật.

Luôn xác nhận trước. Gọi mà không có confirm để lấy sự cố, cho người dùng biết họ đang đóng báo động nào và kết quả là gì, và chỉ gọi lại với confirm: true sau khi họ đồng ý.

Trong một workflow, hoặc từ một Agent, thao tác này chỉ hoạt động khi kế hoạch ứng phó của cơ sở cho phép workflow xác nhận, giải quyết và kích hoạt báo động.

Đọc cài đặt Duress: kế hoạch ứng phó (ai được cảnh báo, theo thứ tự nào và bằng cách nào, tại một cơ sở hoặc dưới dạng mẫu của thương hiệu), kế hoạch đã xác định mà hệ thống báo động thực sự sử dụng, những người và vai trò có thể thêm, cảnh báo thiết bị (pin, ngoại tuyến, vùng phủ sóng và sự cố gửi), quy tắc liên hệ và trạng thái kế hoạch của thương hiệu, tổng quan nút của thương hiệu hoặc tổ chức, và nơi báo động được chuyển đến trung tâm giám sát.

Một cơ sở tuân theo mẫu của thương hiệu (nếu không thì của tổ chức), mở rộng mẫu với các liên hệ bổ sung (mode extend), hoặc thay thế bằng kế hoạch riêng (mode replace). Thay đổi cài đặt bằng duress_settings_write. Thời gian theo định dạng ISO.

Các hành động:

• response_plan: Kế hoạch ứng phó. Kế hoạch đang có hiệu lực tại một cơ sở (effective) và nội dung của từng cấp (sources: facility, brand, organisation), hoặc chỉ với brandId là mẫu của thương hiệu. Các liên hệ ở dạng đã lưu, sẵn sàng để chỉnh sửa và lưu lại.
• resolved_plan: Kế hoạch đã xác định. Những ai hệ thống báo động liên hệ tại cơ sở, theo từng tầng: vai trò được mở rộng thành người, các kênh có thể liên lạc với từng người, độ trễ, và các cảnh báo cần khắc phục trước khi có báo động. Chỉ có tên, không có số điện thoại hoặc email.
• contact_options: Tùy chọn liên hệ. Những người và vai trò có thể thêm vào kế hoạch của cơ sở (cần Duress Configuration tại đó), hoặc chỉ với brandId là vào mẫu của thương hiệu, sau khi áp dụng quy tắc liên hệ của thương hiệu.
• device_alerts: Cảnh báo thiết bị. Ai được thông báo về pin yếu, nút ngoại tuyến, mất vùng phủ sóng và gửi thất bại: các quy tắc ở từng cấp và những người nhận đã xác định của cơ sở, hoặc chỉ với brandId là các quy tắc của thương hiệu.
• contact_rules: Quy tắc liên hệ của thương hiệu. Những vai trò mà các cơ sở trong thương hiệu có thể thêm vào kế hoạch: allowAllExcept ẩn các vai trò được liệt kê, manual chỉ cung cấp các vai trò đó. Cần quyền tương tự như khi chỉnh sửa kế hoạch của thương hiệu. Cần brandId.
• plan_status: Trạng thái kế hoạch của thương hiệu. Mỗi cơ sở trong thương hiệu: tuân theo mẫu, mở rộng mẫu hay có kế hoạch riêng, đã thêm bao nhiêu liên hệ, và các cảnh báo của kế hoạch. Cần brandId.
• buttons_summary: Tổng quan nút. Mọi cơ sở trong một thương hiệu hoặc tổ chức: số nút, số nút pin yếu và ngoại tuyến, bài kiểm tra tiếp theo và gần nhất. Dữ liệu của các trang tổng quan Brands & Customisation và tổ chức.
• monitoring: Định tuyến đến trung tâm giám sát. Cách báo động được chuyển ra khỏi cơ sở: eaAlarmType none, cid (cuộc gọi đến trung tâm giám sát qua eaAlarmProvider) hoặc relay (bảng điều khiển có dây qua eaRelayModel), và các nhà cung cấp có thể sử dụng.

Thay đổi cài đặt Duress: kế hoạch ứng phó (tại một cơ sở, hoặc mẫu của thương hiệu hay tổ chức), cảnh báo thiết bị, quy tắc liên hệ của thương hiệu, và nơi báo động được chuyển đến trung tâm giám sát. Mọi thay đổi đều yêu cầu xác nhận vì chúng thay đổi người được cảnh báo.

Truyền một trong facilityId (mặc định: cơ sở đang kết nối), brandId hoặc organisationId. Kế hoạch của cơ sở cần Duress Configuration tại đó; mẫu cần một quản trị viên tổ chức có Duress Configuration, hoặc với thương hiệu là Duress Configuration tại mọi cơ sở trong thương hiệu. Hãy đọc trước bằng duress_settings_read.

Các hành động:

• save_response_plan: Lưu kế hoạch ứng phó. Các tầng liên hệ được cảnh báo sau afterSeconds kể từ lượt nhấn (tăng dần, tầng đầu tiên thường là 0), ackRequired, reminders và responseActions. Thay vào đó, một cơ sở có thể mở rộng mẫu của mình (mode extend) bằng các phần bổ sung. Các trường bị bỏ qua giữ nguyên giá trị đã lưu; responseActions được hợp nhất theo hành động. Yêu cầu xác nhận.
• remove_response_plan: Gỡ kế hoạch ứng phó. Xóa kế hoạch đã lưu ở cấp này, để cơ sở lại tuân theo mẫu của mình và thương hiệu quay về mẫu của tổ chức. Yêu cầu xác nhận.
• save_device_alerts: Lưu cảnh báo thiết bị. Thay thế các quy tắc cảnh báo thiết bị ở cấp này: tối đa 10 quy tắc, mỗi quy tắc là một tập hợp sự kiện và liên hệ (push, sms hoặc email). Giữ ID quy tắc đọc từ duress_settings_read device_alerts. Cần rules. Yêu cầu xác nhận.
• remove_device_alerts: Gỡ cảnh báo thiết bị. Xóa các quy tắc cảnh báo thiết bị ở cấp này, để cấp này lại tuân theo cấp trên. Yêu cầu xác nhận.
• save_contact_rules: Lưu quy tắc liên hệ của thương hiệu. Những vai trò mà các cơ sở của thương hiệu có thể thêm vào kế hoạch: allowAllExcept ẩn roleIds, manual chỉ cung cấp roleIds. Các liên hệ đã lưu được giữ nguyên; kế hoạch đã xác định được làm mới. Cần brandId, mode, roleIds. Yêu cầu xác nhận.
• save_monitoring: Lưu định tuyến đến trung tâm giám sát. Nơi báo động được chuyển đến: eaAlarmType none, cid (cần eaAlarmProvider, một trong các nhà cung cấp mà duress_settings_read monitoring liệt kê) hoặc relay (eaRelayModel). Cần Duress Configuration tại cơ sở. Cần eaAlarmType. Yêu cầu xác nhận.

Phong tỏa cơ sở khi có báo động khẩn cấp: mọi cửa ngừng cho người vào cho đến khi lệnh phong tỏa được dỡ bỏ (duress_lift_lockdown, hoặc từ bảng điều khiển). Mỗi báo động chỉ có một lần phong tỏa.

Không bao giờ dùng cho báo động kiểm tra hoặc đã giải quyết. Cần Door/Gate Access tại cơ sở.

Xác nhận trước. Gọi mà không có confirm để kiểm tra sự cố, cho người dùng biết mọi cửa sẽ bị khóa, và gọi lại với confirm: true khi họ đồng ý.

Bắt đầu ngay một bài kiểm tra báo động tại một cơ sở. Cho đến khi kết thúc, mọi lượt nhấn đều là kiểm tra, không phải báo động thật:

• walk: nhân viên nhấn từng nút; chỉ bước đầu tiên của kế hoạch ứng phó được cảnh báo, có gắn nhãn TEST.
• drill: toàn bộ kế hoạch ứng phó được chạy, có gắn nhãn TEST.

Các liên hệ kiểm tra của cơ sở được thông báo khi bài kiểm tra bắt đầu và nhận kết quả khoảng 10 phút sau khi kết thúc. Mỗi cơ sở chỉ chạy một bài kiểm tra tại một thời điểm. Kết thúc sớm bằng duress_end_test; đặt lịch kiểm tra trước bằng duress_tests_write.

Xác nhận trước. Gọi mà không có confirm, cho người dùng biết các lượt nhấn sẽ không kích hoạt báo động thật trong durationMinutes, và gọi lại với confirm: true khi họ đồng ý. Trong một workflow, hoặc từ một Agent, thao tác này chỉ hoạt động khi kế hoạch ứng phó của cơ sở cho phép workflow xác nhận, giải quyết và kích hoạt báo động.

Đọc các bài kiểm tra nút báo động: các lịch đặt kiểm tra (walk, comms hoặc drill, một lần hoặc lặp lại, cho một tổ chức, thương hiệu hoặc cơ sở), các khoảng thời gian kiểm tra mà lịch tạo ra tại mỗi cơ sở (scheduled, active, completed, cancelled, cùng các bài kiểm tra đột xuất), và kết quả của một khoảng thời gian kiểm tra (nút nào đã được nhấn hoặc bị bỏ sót, ai đã được thông báo, tín hiệu đến trung tâm giám sát, thời gian xác nhận).

Thông tin về người đã đặt, thay đổi hoặc hủy bài kiểm tra không được bao gồm; người nhận thông báo được ẩn. Thời gian theo định dạng ISO; localDate và localStartTime theo múi giờ của cơ sở. Đặt lịch hoặc thay đổi bài kiểm tra bằng duress_tests_write; bắt đầu ngay một bài kiểm tra bằng duress_start_test.

Các hành động:

• schedules: Lịch kiểm tra. scope facility (mặc định; mọi lịch áp dụng cho cơ sở, bao gồm cả các lịch dùng chung mà cơ sở bỏ qua hoặc thay thế), brand (brandId) hoặc organisation (mặc định: tổ chức của cơ sở). Thay đổi mới nhất trước.
• windows: Khoảng thời gian kiểm tra. Các khoảng thời gian kiểm tra của một cơ sở từ from đến to (mặc định từ khoảng một tuần trước đến một tháng tới), hoặc chỉ với organisationId là các khoảng thời gian sắp tới của tổ chức trên các cơ sở của tổ chức.
• results: Kết quả kiểm tra. Một khoảng thời gian kiểm tra và kết quả: được lưu sau khi gửi, tính trực tiếp khi bài kiểm tra đang chạy (danh sách kiểm tra walk-test), null với các khoảng thời gian đã lên lịch hoặc đã hủy. Cần Duress tại cơ sở. Cần startsAtKey.

Đặt, thay đổi và hủy lịch kiểm tra duress, thiết lập cách một cơ sở tuân theo một lịch dùng chung, và hủy một khung giờ kiểm tra sắp tới. Mọi thay đổi đều đặt hoặc ghi lại các khung giờ trong tương lai và gửi email cho các bên liên quan, vì vậy mỗi thao tác đều yêu cầu xác nhận.

Lịch cần quyền Duress Configuration trên toàn bộ phạm vi mục tiêu (quản trị viên tổ chức đối với lịch áp dụng toàn tổ chức). Thời gian tính theo múi giờ của từng cơ sở. Hãy đọc lịch và khung giờ trước bằng duress_tests_read; bắt đầu kiểm tra ngay bằng duress_start_test.

Các hành động:

• create_schedule: Đặt lịch kiểm tra. Đặt các khung giờ trước tối đa khoảng một năm tại mọi cơ sở trong target và gửi email xác nhận đặt lịch. Cần name, type, target, startDate, localStartTime và recurrence. Cần name, type, target, startDate, localStartTime, recurrence. Yêu cầu xác nhận.
• update_schedule: Thay đổi lịch kiểm tra. Các trường không được gửi sẽ giữ nguyên giá trị. Các khung giờ trong tương lai được ghi lại (các khung giờ đã bắt đầu được giữ nguyên) và các bên liên quan nhận được thông báo thay đổi. Sau đó hãy dùng ownerScope trong kết quả. Cần ownerScope, scheduleId. Yêu cầu xác nhận.
• cancel_schedule: Hủy lịch kiểm tra. Hủy lịch và các khung giờ trong tương lai của lịch, đồng thời gửi email thông báo hủy. Các cơ sở có bản sao riêng vẫn giữ bản sao đó. Cần ownerScope, scheduleId. Yêu cầu xác nhận.
• set_facility_override: Thay đổi lịch dùng chung cho một cơ sở. mode follow (chạy lại lịch dùng chung tại đây), skip (dừng lịch tại đây) hoặc own (thay thế lịch tại đây bằng một bản sao tạo từ schedule). Chỉ cần quyền Duress Configuration tại cơ sở đó. Cần ownerScope, scheduleId, mode. Yêu cầu xác nhận.
• cancel_window: Hủy một khung giờ kiểm tra. Hủy một lần kiểm tra đã lên lịch tại một cơ sở (lịch vẫn tiếp tục) và gửi email cho các bên liên quan. Cần quyền Duress tại cơ sở; lần kiểm tra đang diễn ra thì được kết thúc bằng duress_end_test. Cần startsAtKey. Yêu cầu xác nhận.

Mở khóa các cửa cho một báo động duress, ví dụ để cảnh sát hoặc nhân viên sơ cứu vào: các cửa được liên kết với nút đã nhấn, nếu không thì các cửa trong kế hoạch phản ứng. Bỏ qua doorIds để mở tất cả, hoặc liệt kê một số cửa. Mỗi lần mở khóa đều được ghi trên dòng thời gian sự cố và trong Nhật ký truy cập.

Không bao giờ dùng cho báo động kiểm tra hoặc báo động đã được xử lý. Cần quyền Door/Gate Access tại cơ sở.

Xác nhận trước. Gọi không kèm confirm để xem những cửa nào sẽ được mở khóa, thông báo cho người dùng, rồi gọi lại với confirm: true khi họ đồng ý.