Ok, chyba za dużo podałem uzasadnienia a za mało opisu problemu 🙂
No więc potrzebuję konfiguracji, dzięki której nie można zmienić terminu zamkniętego spotkania - trzeba to spotkanie otworzyć, żeby zmienić termin (takie zabezpieczenie przed pomyłkami).
EPESI ma rozbudowany system dostępu, który pozwala na taką konfigurację:
- Typ dostępu: Edytuj
- Wymagany poziom uprawnień: Dostęp: Employee
- Odnosi się do rekordów: Dostęp jest równy Publiczny lub Pracownicy jest równy Kontakt Użytkownika lub Klienci jest równy Kontakt Użytkownika i Status nie jest równy Zamknięty
- Pola: 17 / 17
Przy takiej konfiguracji jest ok, nie można zmieniać nic w zamkniętym spotkaniu zarówno z poziomu edycji jak i drag&drop w kalendarzu.
Następnie chcę dać możliwość zmiany tylko statusu dla zamkniętego spotkania, w uproszczeniu to będzie:
- Typ dostępu: Edytuj
- Wymagany poziom uprawnień: Dostęp: Employee
- Odnosi się do rekordów: Status jest równy Zamknięty
- Pola: 1 / 17 (tylko status)
Przy takiej konfiguracji jest ok, ale tylko z poziomu edycji - można zmieniać tylko status w zamkniętym spotkaniu. Niestety z poziomu kalendarza działa z sukcesem drag&drop, które pozwala zmienić datę.
Wyglądało mi na to, że brak dostępu do zmiany daty jest ignorowany przez mechanizm drag&drop - ale to większy problem:
[quote:1hqhx78d] Synchronizacja Drag&Drop z uprawnieniami Record Browsera wymagałaby pisania dodatkowego kodu a mamy inne, ważniejsze priorytety.[/quote:1hqhx78d]
Ok, rozumiem... można z tym żyć.
Pozdrowienia z Lublina,
Mariusz
PS. Tak przy okazji chciałbym pogratulować pomysłów twórcom systemu. Cały ten system jest na prawdę imponująco wygodny i daje duże możliwości konfiguracyjne. Zaskoczyło mnie, że dodanie atrybutu jest realizowane jako dodanie kolumny w tabeli na bazie danych... bezkompromisowe, niby operacja DDL ale jest to z korzyścią dla wydajności! Brakuje mi też lepszego podziału na warstwy - idealnie by było, żeby cały frontend gadał z backendem przez restful...
