Planowanie i rezerwacja zasobów w Open Mercato: granice dostępności i booking

Słownik możliwości i dowodów

• available
• configurable
• custom
• integration-required

• latest public release
• current develop
• current first-party documentation
• specification or plan
• external primary requirement
• editorial recommendation

Not established in reviewed evidence opisuje wniosek z analizy dowodów. Model możliwości nadal ma cztery stany.

Piętnaście pojęć, które muszą pozostać odrębne

Niedostępny, dozwolony i zobowiązany to różne stany

Zapisz źródło, czas, zakres, ilość, autorytet i confidence przed pokazaniem wyniku użytkownikowi.

• 1. Niedostępny według bieżącej reguły
• 2. Reguły zezwalają na ten czas; stan rezerwacji pozostaje nieznany
• 3. Wolny lub zarezerwowany dopiero po sprawdzeniu autorytatywnego rejestru zobowiązań

Połączone okno plannera wskazuje, na co zezwalają reguły dostępności. Nie pokazuje, czy zasób jest wolny po uwzględnieniu zobowiązań, hold, potwierdzeń, płatności ani warunków dostępu fizycznego. Tłumacz dostępny jako niezarezerwowany dopiero po sprawdzeniu autorytatywnego rejestru.

Bieżący rekord zasobu i granica modułów

Sklasyfikuj jako metadata, control, reference lub timestamp; przypisz cel, edytora, czytelnika, walidację, retencję i odbiór.

• 1. Nazwa i opis
• 2. Opcjonalny id typu zasobu
• 3. Metadana dodatniej pojemności całkowitej
• 4. Wartość jednostki pojemności
• 5. Nazwa jednostki pojemności
• 6. Kolor i ikona jednostki pojemności
• 7. Ikona i kolor zasobu
• 8. Stan aktywności
• 9. Id zestawu reguł dostępności
• 10. Zakres tenantu i organizacji
• 11. Czas utworzenia i zmiany
• 12. Czas soft delete
• 13. Typy
• 14. Tagi
• 15. Pola własne
• 16. Komentarze
• 17. Aktywności
• 18. Załączniki, wyszukiwanie i historia wersji

Domyślna aplikacja osobno rejestruje planner i resources z @open-mercato/core, a resources deklaruje zależność od planner. Oba są w bieżącym kodzie MIT i ejectable. Każde wdrożenie musi nadal sprawdzić, czy moduły są włączone i skonfigurowane. Domyślny registry opisuje wyłącznie sprawdzoną aplikację. Typy zasobów są kategoriami w zakresie, a tagi elastycznymi etykietami. Nie definiują dziedziczonej polityki rezerwacji. Komentarze, aktywności, załączniki, podgląd wiadomości, wyszukiwanie i historia zapewniają powierzchnie rekordu operacyjnego. Nie zapewniają systemów maintenance, DMS, messaging ani compliance.

Inwentarz macierzy możliwości

Przypisz jeden wspólny capability state, evidence label, sprawdzoną powierzchnię, rewizję i datę, ograniczenie, confidence, właściciela operacyjnego i następny krok odbioru.

• 1. Rekordy master zasobów
• 2. Typy zasobów
• 3. Tagi
• 4. Atrybuty własne
• 5. Metadane pojemności
• 6. Snapshot jednostki pojemności
• 7. Cykl active i soft delete
• 8. Komentarze
• 9. Aktywności
• 10. Załączniki
• 11. Podgląd obiektu wiadomości
• 12. Wyszukiwanie
• 13. Historia wersji
• 14. Zakres tenantu i organizacji
• 15. Uprawnienia resources
• 16. Uprawnienia planner
• 17. Zestawy reguł dostępności
• 18. Tygodniowa dostępność
• 19. Dostępność dla daty
• 20. Blokująca niedostępność
• 21. Połączone okna dozwolone
• 22. Optymistyczne blokady konfiguracji
• 23. Chronione mutacje konfiguracji
• 24. Agregat rezerwacji
• 25. Atomowe zapobieganie konfliktom
• 26. Zużycie pojemności
• 27. Publiczny kanał rezerwacji
• 28. Akceptacje i lista oczekujących
• 29. Check-in i no-show
• 30. Powiązanie płatności i zamówienia
• 31. Synchronizacja kalendarza
• 32. Integracja systemu specjalistycznego

Pojemność przyjmuje dodatnią liczbę całkowitą i zapisuje snapshot etykiety oraz prezentacji jednostki. Sprawdzony kod nie rezerwuje tej wartości ani jej nie zmniejsza. Nie sumuje jej też ani nie egzekwuje. Wartość taka jak 12 spots jest metadaną i nie może bezpiecznie sprzedawać ani przydzielać jednostek bez atomowego modelu alokacji.

Dowody z runtime wyznaczają granicę rezerwacji

Dokumentacja projektu Open Mercato nazywa zasoby reservable items i podaje one-off reservations jako przykład dla daty. Bieżący runtime zapisuje wyjątek dostępności lub niedostępności dla daty. Nie tworzy tożsamości rezerwacji, klienta, ilości, stanu, decyzji konfliktu, cyklu anulowania ani rekordu uzgodnienia. Taki wyjątek może ręcznie blokować czas powiązany z zewnętrznym zobowiązaniem. Rejestr zewnętrzny lub custom pozostaje autorytatywny.

Wspólny AvailabilityRulesEditor ma opcjonalny hook loadBookedEvents. Sprawdzony caller szczegółu zasobu go nie przekazuje, więc booked events nie są tam ładowane. Punkt rozszerzenia komponentu, translation string, nieużywana stała, seed, stary endpoint demo /booking i snippet wyszukiwania nie dostarczają funkcji rezerwacji w tej rewizji.

Cykliczność i czas cywilny wymagają wąskiego twierdzenia odbioru

• DTSTART
• DURATION
• Częstotliwość DAILY
• Częstotliwość WEEKLY
• Opcjonalny COUNT
• Daty wyjątków i dzienne nadpisania jednorazowe

Sprawdzony helper merge rozpoznaje ten wąski subset o kształcie RRULE, używa parsowania zorientowanego na UTC oraz stałej arytmetyki 24 godzin lub 7 dni i obsługuje jednorazowe nadpisania na poziomie dnia. Validator przyjmuje niepusty tekst strefy; walidacja identyfikatora IANA nie jest tam potwierdzona. Sprawdzony helper nie obsługuje pełnej cykliczności RFC 5545, dowolnego importu lub eksportu kalendarza, zachowania CalDAV, uniwersalnej poprawności DST ani interoperacyjności kalendarzy. Traktuj te obszary jako ryzyka odbioru. Sprawdzone dowody nie pozwalają stwierdzić defektu ani gwarancji.

Zdefiniuj intencję lokalną, zapisaną chwilę, oczekiwane wystąpienia, tożsamość anulowania, dowód, ownera i kryterium pass w wdrożonym runtime.

• 1. Zmiana na czas letni: brakujący czas lokalny
• 2. Zmiana na czas zimowy: powtórzony czas lokalny
• 3. Start lub koniec o północy
• 4. Przedział przez zmianę daty
• 5. Dzień przestępny
• 6. Wiele stref prezentacji
• 7. UTC wobec intencji czasu lokalnego
• 8. Edycja serii po wystąpieniach
• 9. Tożsamość wyjątku anulowania
• 10. Aktualizacja danych stref IANA

RFC 5545 · Dane stref IANA

Redakcyjny blueprint agregatu rezerwacji

Ten redakcyjny model wdrożenia opisuje pracę projektową. Nie opisuje bieżącego zachowania Open Mercato. Dopasuj agregat i cykl do faktycznej domeny, autorytetu i skutku konfliktu.

• Requested
• Held
• Awaiting approval
• Confirmed
• Checked in
• Completed
• Cancelled
• Expired
• Rejected
• No-show

Nazwij system of record, primary id, wersję, mechanizm zmiany, ownera, cel latency, regułę uzgodnienia i właściciela wyjątku.

• 1. Stan reguły dostępności
• 2. Stan rezerwacji
• 3. Stan kalendarza zewnętrznego
• 4. Stan zamówienia
• 5. Stan płatności
• 6. Stan powiadomienia
• 7. Stan dostępu fizycznego

Zapobieganie konfliktom musi commitować atomowo

Dla zasobu wyłącznego sprawdź aktywne konkurencyjne zobowiązania i zapisz nowe w tej samej transakcji lub równoważnej kontroli atomowej. Dla puli pojemności zsumuj aktywny popyt i commituj nową ilość w tej samej chronionej granicy. Check wykonany osobno przed write może się ścigać. Bieżące optimistic locks konfiguracji zasobu i dostępności ograniczają utratę zmian konfiguracji; nie rozstrzygają dwóch żądań rezerwacji, bo sprawdzony booking write nie istnieje.

Podaj równoległy setup, idempotencję, granicę lock, dozwolony wynik, zabroniony duplikat lub over-capacity, recovery, uzgodnienie i dowód.

• 1. Dwie równoległe rezerwacje wyłącznego zasobu
• 2. Równoległy popyt przekraczający pojemność
• 3. Retry z tym samym kluczem idempotencji
• 4. Retry z innym kluczem
• 5. Wygaśnięcie hold wobec potwierdzenia
• 6. Anulowanie wobec potwierdzenia
• 7. Zmiana rezerwacji wobec usunięcia zasobu
• 8. Zmiana serii wobec wyjątku wystąpienia

Wytyczne OWASP dla race w logice biznesowej

Jawnie zdefiniuj polityki rezerwacji

Sklasyfikuj jako configurable, custom lub integration-required z autorytetem, wersją, miejscem egzekwowania, wyjątkiem i dowodem odbioru.

• 1. Bufor przygotowania
• 2. Bufor sprzątania
• 3. Wyprzedzenie
• 4. Horyzont rezerwacji
• 5. Minimalny czas
• 6. Maksymalny czas
• 7. Krok rezerwacji
• 8. Blackout
• 9. Okno anulowania
• 10. Akceptacja
• 11. Lista oczekujących
• 12. Check-in
• 13. No-show
• 14. Seria cykliczna
• 15. Wyjątki serii
• 16. Zmiana przydziału
• 17. Reguła nadrezerwacji
• 18. Obsługa walk-in

Nieużywane stałe API, teksty tłumaczeń, demo i snippety wyszukiwania nie definiują default duration ani bufferów.

Kanał publiczny jest osobną powierzchnią produktu i ryzyka

Nazwij ownera, dowód, przypadek nadużycia, awarię, korektę, retencję i warunek stop. W planner/resources nie potwierdzono publicznej strony rezerwacji ani flow wizyty klienta.

• 1. Rezerwacja operatora wewnętrznego
• 2. Strona publiczna lub samoobsługowa
• 3. Uwierzytelnienie i tożsamość zgłaszającego
• 4. Rate limiting i anti-abuse
• 5. Prywatność i minimalizacja danych
• 6. Dostępność cyfrowa
• 7. Zgody i warunki
• 8. Komunikacja z klientem
• 9. Handoff płatności i zwrotu
• 10. Wsparcie i ścieżka korekty

Drzewo systemu źródłowego i integracja zewnętrzna

1. 1

   Czy Open Mercato może posiadać domenowy cykl rezerwacji i atomową kontrolę konfliktu?

2. 2

   Jeśli tak, zbuduj i odbierz custom aggregate przed nazwaniem slotów wolnymi

3. 3

   Jeśli nie, pozostaw scheduler specjalistyczny autorytatywny

4. 4

   Dla modelu hybrid przypisz autorytet per pole i stan

5. 5

   Uzgadniaj każdy wyjątek i zapewnij ręczne recovery

Jednokierunkowy feed kalendarza nie tworzy conflict-safe rezerwacji two-way. Synchronizacja two-way wymaga tożsamości, wersji lub sequence, reguł organizatora i uczestnika, projekcji prywatności, tożsamości serii i wyjątku, usunięcia i tombstone, pochodzenia i zapobiegania pętli, właściciela konfliktu, retry i uzgodnienia.

Kontrole dostępu do dostępności nie obejmują akceptacji rezerwacji

Bieżący resolver dostępności rejestrowany przez staff odróżnia manage-all od self service powiązanego profilu; API keys nie otrzymują tej gałęzi self service, a brak resolvera staff zamyka dostęp. Te kontrole obejmują zapis dostępności. Nie zapewniają tożsamości zgłaszającego, akceptacji rezerwacji, ownership branch lub zasobu, rozdzielenia override authority, dostępu publicznego ani współdzielenia cross-organization.

Macierz odpowiedzialności

Przypisz responsible, accountable, consulted i informed, właściciela wyjątku, zastępstwo, dowód i release authority.

• 1. Master data zasobów
• 2. Dostępność i reguły cykliczne
• 3. Nadpisania i wyjątki
• 4. Polityka rezerwacji
• 5. Operacje rezerwacji
• 6. Wyjątki konfliktu i pojemności
• 7. Wsparcie klienta i korekta
• 8. Integracje kalendarza i systemu specjalistycznego
• 9. Prywatność i dane wrażliwe
• 10. Odbiór wydania i rollback

Złożona praca wymagająca osoby i sali, pojazdu lub sprzętu potrzebuje jednej wspólnej granicy zobowiązania albo modelu kompensującego. Dostępność osoby, urlop, czas i autorytet workforce pozostają w przewodniku staff; ilość stock i rezerwacja magazynowa pozostają w przewodniku inventory.

Rejestr danych wrażliwych

Zdefiniuj cel, dozwolonego czytelnika i edytora, retencję, korektę, usunięcie i eksport, ekspozycję search i log, dowód szyfrowania, kopię downstream i właściciela.

• 1. Opisy i wolny tekst
• 2. Instrukcje lub kody dostępu
• 3. Numery seryjne i dane pojazdów
• 4. Dane utrzymania i incydentów
• 5. Referencje zgłaszającego lub klienta
• 6. Cel rezerwacji
• 7. Dane organizatora i uczestników
• 8. Metadane kalendarza i dostępu fizycznego

Sprawdzony kod planner/resources nie definiuje module-specific default encryption map. Sprawdzony kod nie potwierdza, czy generic platform, polityka pól własnych, załączniki, infrastruktura lub overlays szyfrują wdrożenie. Sprawdź każde źródło. Nigdy nie wpisuj sekretów, kodów dostępu, danych zdrowotnych ani zbędnych danych osobowych w wolnym tekście.

Trzy syntetyczne architektury

Zapisz bieżący dowód, wybór architektury, system of record, ryzyko, ownera, przypadki odbioru, warunki stop i następny krok discovery.

Słabe dopasowanie bez zweryfikowanego autorytetu specjalistycznego

• Hotelowy PMS i channel management: brakuje kontroli cyklu domeny, polityki, konfliktu, pojemności, bezpieczeństwa, integracji lub dowodów; Open Mercato może przechować wybrane referencje lub orkiestrować tylko ograniczone kroki.
• Healthcare lub regulowane wizyty: brakuje kontroli cyklu domeny, polityki, konfliktu, pojemności, bezpieczeństwa, integracji lub dowodów; Open Mercato może przechować wybrane referencje lub orkiestrować tylko ograniczone kroki.
• Grafiki workforce i ewidencja czasu: brakuje kontroli cyklu domeny, polityki, konfliktu, pojemności, bezpieczeństwa, integracji lub dowodów; Open Mercato może przechować wybrane referencje lub orkiestrować tylko ograniczone kroki.
• APS lub MRP o skończonej pojemności: brakuje kontroli cyklu domeny, polityki, konfliktu, pojemności, bezpieczeństwa, integracji lub dowodów; Open Mercato może przechować wybrane referencje lub orkiestrować tylko ograniczone kroki.
• Dispatch serwisu terenowego: brakuje kontroli cyklu domeny, polityki, konfliktu, pojemności, bezpieczeństwa, integracji lub dowodów; Open Mercato może przechować wybrane referencje lub orkiestrować tylko ograniczone kroki.
• Telematyka floty: brakuje kontroli cyklu domeny, polityki, konfliktu, pojemności, bezpieczeństwa, integracji lub dowodów; Open Mercato może przechować wybrane referencje lub orkiestrować tylko ograniczone kroki.
• Enterprise desk booking: brakuje kontroli cyklu domeny, polityki, konfliktu, pojemności, bezpieczeństwa, integracji lub dowodów; Open Mercato może przechować wybrane referencje lub orkiestrować tylko ograniczone kroki.
• CMMS lub EAM: brakuje kontroli cyklu domeny, polityki, konfliktu, pojemności, bezpieczeństwa, integracji lub dowodów; Open Mercato może przechować wybrane referencje lub orkiestrować tylko ograniczone kroki.
• Inventory miejsc i ticketing: brakuje kontroli cyklu domeny, polityki, konfliktu, pojemności, bezpieczeństwa, integracji lub dowodów; Open Mercato może przechować wybrane referencje lub orkiestrować tylko ograniczone kroki.
• Umowy najmu i obsługa szkód: brakuje kontroli cyklu domeny, polityki, konfliktu, pojemności, bezpieczeństwa, integracji lub dowodów; Open Mercato może przechować wybrane referencje lub orkiestrować tylko ograniczone kroki.
• Publiczny marketplace: brakuje kontroli cyklu domeny, polityki, konfliktu, pojemności, bezpieczeństwa, integracji lub dowodów; Open Mercato może przechować wybrane referencje lub orkiestrować tylko ograniczone kroki.

Czynniki stop lub go

Nazwij próg, autorytet, bieżący dowód, brakującą kontrolę, ownera i obowiązkowy warunek stop.

• 1. Skutek konfliktu
• 2. Ekspozycja kanału publicznego
• 3. Zależność płatności lub zwrotu
• 4. Dane regulowane lub wrażliwe
• 5. Skutek bezpieczeństwa fizycznego
• 6. Istniejący ekosystem kalendarzy
• 7. Złożoność cykliczności i stref
• 8. Skala wolumenu i współbieżności

Warunkowy pakiet go-live

Wymagaj dowodu, ownera, wyjątku, recovery i warunkowego sign-off. Ten pakiet nie przyznaje oceny ani certyfikacji.

• 1. Włączone moduły planner i resources
• 2. Właściciel taksonomii zasobów
• 3. Semantyka pojemności
• 4. Autorytatywny rejestr zobowiązań
• 5. Atomowy zapis wyłącznego zasobu
• 6. Atomowy zapis popytu na pojemność
• 7. Idempotencja i retry
• 8. Worker wygaśnięcia hold i recovery
• 9. Wersjonowanie polityki
• 10. Identyfikatory stref
• 11. Utrzymanie danych stref IANA
• 12. Odbiór DST i cykliczności
• 13. Dostęp i zabronione kombinacje
• 14. Anti-abuse kanału publicznego
• 15. Prywatność i retencja
• 16. Zapobieganie pętli kalendarza
• 17. Dead letter i kolejka wyjątków
• 18. Uzgodnienie
• 19. Ścieżka korekty klienta
• 20. Handoff płatności i zamówienia
• 21. Monitoring i alerty
• 22. Backup i recovery
• 23. Rollback
• 24. Plan ciągłości ręcznej
• 25. Warunkowy sign-off właściciela

Pakiet odbioru

Podaj setup, współbieżnych actorów, abstrakcyjne ids, sekwencję stanów, oczekiwany dowód autorytatywny i lokalny, zabroniony wynik, failure injection, korektę, uzgodnienie, ownera i kryterium pass.

• 1. Izolacja draft route
• 2. Odświeżenie registry modułów
• 3. Utworzenie i odczyt scoped zasobu
• 4. Zachowanie typu i tagu
• 5. Pojemność pozostaje metadaną
• 6. Tygodniowe okno dostępności
• 7. Dozwolone nadpisanie daty
• 8. Blokada dla daty
• 9. Brak caller booked events
• 10. Kwalifikacja słownictwa dokumentacji
• 11. DTSTART i DURATION
• 12. Cykliczność DAILY i WEEKLY
• 13. Granica COUNT
• 14. Data wyjątku
• 15. DST forward
• 16. DST back
• 17. Północ
• 18. Dzień przestępny
• 19. Wiele stref
• 20. Edycja cykliczności
• 21. Równoległe żądanie wyłącznego zasobu
• 22. Równoległe żądanie pojemności
• 23. Ten sam klucz idempotencji
• 24. Inny klucz retry
• 25. Wygaśnięcie hold
• 26. Anulowanie wobec potwierdzenia
• 27. Zmiana wobec usunięcia
• 28. Wyjątek serii i race
• 29. Konflikt optymistyczny zasobu
• 30. Konflikt optymistyczny dostępności
• 31. Odmowa cross-organization
• 32. Dostępność manage-all
• 33. Self service powiązanego profilu
• 34. Odmowa self service dla API key
• 35. Brak resolvera fail closed
• 36. Granica kalendarza one-way
• 37. Wersja i pętla two-way
• 38. Usunięcie zewnętrzne i tombstone
• 39. Mapowanie wyjątku cyklicznego
• 40. Atomowe powiązanie osoby i sali
• 41. Uwierzytelnienie publiczne
• 42. Publiczne anti-abuse
• 43. Dostępność cyfrowa
• 44. Minimalizacja danych wrażliwych
• 45. Brak nadmiernego twierdzenia o szyfrowaniu
• 46. Wyjątek uzgodnienia
• 47. Ręczne recovery
• 48. Bez JavaScript
• 49. Druk i eksport
• 50. Lokalny sentinel prywatności

Warunki stop

• Brak właściciela rejestru zobowiązań.
• Brak atomowego modelu konfliktów, gdy są istotne.
• Znaczenie pojemności jest nieznane.
• Brak odbioru stref i cykliczności.
• Brak właściciela korekty i anulowania.
• Brak uzgodnienia integracji.
• Brak kontroli nadużyć kanału publicznego.
• Dane wrażliwe nie mają celu lub właściciela.
• Wymaganie bezpieczeństwa lub regulowane nie ma autorytetu specjalistycznego.
• Brak dowodów odbioru.

Rejestr źródeł i ścieżka korekty

Evidence label, powierzchnia twierdzenia, rewizja lub data, ograniczenie i review owner zapisane 2026-07-14. Zgłoś korektę z dokładnym twierdzeniem i dowodem zastępczym.

• 1. Bieżący registry modułów develop i runtime planner/resources
• 2. Dokumentacja projektu Open Mercato dotycząca zasobów z szerszym słownictwem reservable
• 3. Publiczne wydanie v0.6.5 i bieżące zmiany post-tag
• 4. Standard iCalendar RFC 5545 jako szersza granica cykliczności
• 5. Dane stref czasowych IANA jako kontekst utrzymania czasu cywilnego
• 6. Wytyczne OWASP logiki biznesowej dla atomowego check-and-commit

Najnowsze sprawdzone wydanie · Niezmienny kod resources · Niezmienny kod planner