Recovery

Ang pahinang Recovery ay ang safety net ng Zellbox para sa mga destructive na aksyon sa mga event. Sa bawat pagkakataon na may malapit nang alisin o ikansela na event mula sa calendar mirror ng workspace, nagsa-snapshot ang Zellbox ng buong row muna sa hiwalay na backup table. May 90 araw kang ibalik ang alinman sa kanila nang isa-isa.

Sakop nito ang limang path:

Source action	Ano ang makikita mo kung nagkamali	Mababawi?
Approve cancellations sa naka-hold na sync branch	Bawat event na tinanggihan ng safety guard ay sinft-cancel sa isang batch	Oo
Sync cancellation (normal, low-volume)	Ang event na iniulat ng Google bilang cancelled ay nawawala mula sa live grid	Oo
Cancel event (pag-click ng operator)	Lumilipat ang event sa status: cancelled na may dahilan	Oo
Delete event (pag-click ng operator, hard delete)	Inaalis ang event row mula sa mirror	Oo
Reset calendar data	Bawat event row, paalala, at tracked-calendar selection ay nililinis sa isang shot	Oo — ito ang pinakamalaking dahilan ng feature na ito

Ibinabalik ng Restore ang event sa Zellbox bilang bagong row. Hindi ito muling itinutulak sa Google Calendar nang awtomatiko — hiwalay na desisyon iyon na may implication sa invite-email.

Saan mahahanap

Sidebar → Setup at Tulong → Recovery (o buksan ang /recovery nang direkta). Pareho ang nakikita ng admin at privileged tier; nakikita lang ng mga miyembro ang sariling backup.

Ano ang makikita mo

Reverse-chronological na listahan ng bawat event na sinapshot ng Zellbox sa piniling window. Ang default filter ay "Huling 30 araw, lahat ng dahilan", na sumasaklaw sa lahat ng nasa loob ng 90-araw na TTL na malamang na nangangailangan ng atensyon.

Ang bawat row ay nagpapakita ng:

• Pamagat (mula sa snapshot sa oras ng backup, hindi kung anuman ang ginawa ng event pagkatapos).
• Start time sa workspace time zone.
• Reason chip — Quarantine approved, Sync cancellation, Operator cancelled, Operator deleted, o Reset calendar data.
• Source calendar (ang Google calendar id, kapag kilala).
• Backed up at — kailan isinulat ang snapshot.
• Description preview (unang dalawang linya).
• Restore button, o isang "Naibalik Lun May 27 12:34" na note katabi ng "Ibalik muli" kung naibalik mo na ang snapshot na ito.

Pag-filter

Dalawang filter knob:

• Dahilan dropdown — Lahat ng dahilan (default) o isa sa limang source action sa itaas. Kapaki-pakinabang kapag alam mong aksidenteng inaprubahan ang quarantine at gusto mong tingnan ang mga backup na iyon lamang.
• Time range chips — Huling 24 h / 7 araw / 30 araw (default) / Lahat. Inihahalip ng Lahat ang lahat ng nasa loob pa rin ng 90-araw na TTL.

Pagbabalik ng event

1. Hanapin ang row.
2. I-click ang Restore.
3. Naglalabas ang confirm dialog ng kung ano ang ginagawa ng Restore: muling lumilikha ng event sa Zellbox na may parehong oras, kostumer, manager, at paalala; ibinabalik ang event bilang Zellbox-only at hindi itinutulak pabalik sa Google.
4. I-click ang Restore para kumpirmahin.
5. Lumalabas ang bagong event sa calendar grid sa loob ng isang segundo. Ang customer-link, assigned-manager, reminder offset, visit mode, numero ng telepono — lahat ay napapanatili mula sa snapshot.

Maaari mong ibalik ang parehong snapshot nang maraming beses. Ang bawat Restore ay lumilikha ng bagong mirror row na may sariling eventId; nananatili ang original backup record para sa audit. Kaya kung aksidente kang nag-restore, nag-edit, pagkatapos ay tinanggal ang bagong kopya, puwede mo pa ring ibalik muli ang backup para mabawi.

Ano ang HINDI naibabalik

• Ang mismong Google Calendar event. Nabubuhay ang Restore sa loob lang ng mirror ng Zellbox. Ang orihinal na Google event ay maaaring naka-tombstone (itinuturing na ng Google na cancelled — ang pag-restore locally ay hindi muling bumubuhay nito sa panig ng Google) o ganap na tinanggal. Kung kailangan ng iyong team na bumalik sa Google ang event para makita nila ito sa Google Calendar app, manu-manong gumawa muli ng event doon o gamitin ang per-event "Push to Google" affordance kapag dumating ito.
• Audit history ng orihinal na event. Ang bagong eventId ay nangangahulugang ang bagong mirror row ay nagsisimula sa bagong audit timeline (isinusulat ang audit row na nagli-link pabalik sa source backup id kaya posible pa rin ang forensic query).
• Mga abiso sa kostumer na naipadala na. Kung nag-trigger ang orihinal na event ng "Calendar event cancelled" email sa oras ng pagkansela, ang pag-restore ay hindi binabawi ang pagkapadala. Nagiging gaya ng bagong booking ang bagong event.

Ang 90-araw na retention window

Nabubuhay ang mga backup row sa loob ng 90 araw, pagkatapos ay tinatanggal ng DynamoDB TTL sweep. Pagkatapos noon, ang snapshot ay permanenteng nawawala. Binabalaan ka ng Recovery page kapag nasa loob ng huling linggo ng window ang row para makapagpasya ka kung ire-restore mo ito ngayon o hayaang mawala.

Kung mahahanap mo ang sarili mo malapit sa 90-araw na gilid para sa mahalagang snapshot, ang tamang galaw ay i-restore ang event ngayon — kahit hindi mo pa kailangan — at mag-cancel/ delete muli pagkatapos kung kinakailangan. Ang bawat restore ay lumilikha ng bagong 90-araw na window para sa bagong mirror row.

Paano nagpa-plug ang safety net sa iba pang workflow

Lahat ng apat na destructive surface ay binabanggit na ang Recovery sa kanilang confirmation dialog, kaya alam mong nandiyan ang safety net bago mo i-click ang destructive button:

• Ang confirm dialog ng Sync Status → Approve cancellations ay nagtatapos na ngayon sa backup note. Tingnan ang Sync status.
• Ang confirm dialog ng Google Sync → Reset calendar data ay nagtatapos sa backup note. Tingnan ang Reset.
• Ang mga modal ng Cancel event at Delete event sa kalendaryo ay nagtatapos sa backup note. Tingnan ang Kalendaryo.
• Ang held-events drill-down sa Sync Status ay naglilista ng bawat event na tinanggihan ng guard, kaya makikita mo kung ano ang ibe-back up + pagkatapos ay kakanselahin bago i-click ang Approve.

Forensic trail

Bukod sa Recovery, ang bawat destructive na aksyon ay nagsusulat din ng audit row sa BWS_ZELLBOX_CALENDAR_EVENT_AUDIT_LOG (1-taon na TTL). Sinasagot ng audit log ang "ano ang nangyari sa event X" makaraan ng mga buwan; sinasagot ng Recovery ang "i-restore ang event na ito ngayon". Nag-co-complement sila — para sa operator ang Recovery, para sa post-mortem ang audit log.