Logika
17 godz. 49 min · Biznes i Automatyzacje
Krzysiek PiekarzAutomation Specialist / No-code DeveloperCzy w Twojej głowie pojawił się pomysł na aplikację, która zrewolucjonizuje świat na miarę Facebook'a, Instagrama albo Airbnb? A może zgłosił się do Ciebie klient, który chce przetestować i wdrożyć swój projekt w jak najszybszym czasie?Jeśli tak było to na pewno zadajesz sobie teraz kolejne pytanie - od czego zacząć? Czy muszę posiadać odpowiednią wiedzę programistyczną? Na jaki język programowania się zdecydować lub z jakiego gotowego framework'u skorzystać? A może zatrudnić profesjonalnego designera i software house, który pozwoli mi zrealizować ten projekt?Niezależnie od tego czy czy zdecydujesz się działać sam/a, czy też przekażesz projekt do zewnętrznej agencji i tak staniesz przed kolejnym dylematem jakim jest nauka programowania lub konieczność przepalenia nawet setek tysięcy złoty na coś, co może okazać się niewypałem.Na szczęście szybki rozwój narzędzi no-code sprawia, że możesz wybrać jeszcze trzecie wyjście. Zaprojektować, zbudować i wypuścić w świat swoją wymarzoną aplikację tylko za pomocą własnych sił i to bez konieczności posiadania specjalistycznej wiedzy programistycznej, a nawet posiadając jedynie podstawową znajomość narzędzi do design'u.Pamiętaj również o tym, że projekt ten podzieliłem na dwie części. Ten kurs to druga część, w której zapoznamy się z bardziej zaawansowanymi opcjami, jakie zapewnia nam edytor Bubble. Zdobytą w ten sposób wiedzę teoretyczną wykorzystamy od razu w praktyce dodając do naszego statycznego designu odpowiednią logikę, dzięki czemu nasz finalny projekt będzie już w pełni działającą aplikacją.Jeśli tylko potrafisz w podstawowym zakresie pracować z edytorem Bubble, budować w nim design aplikacji i rozumiesz czym są option sets oraz workflows to posiadanie wiedzy z poprzedniego kursu nie jest koniecznie wymagane. Natomiast szczerze zachęcam Cię przynajmniej do przejrzenia materiałów z pierwszej części, gdzie skupiamy się właśnie na podstawach, ponieważ teraz będziemy efektywnie przechodzić do bardziej zaawansowanych tematów i rozbudowywać naszą aplikację.
W tym kursie „MVP aplikacji w rekordowym czasie z Bubble (Logika)” nauczę Cię jak zamienić statyczny layout na pełnoprawną aplikację. Poruszymy takie tematy jak praca z bazą danych, privacy rules oraz bardziej zaawansowane workflows, które dodamy zarówno na froncie jak i backendzie naszej aplikacji. Dzięki zdobytej wiedzy dodamy logikę wszędzie tam, gdzie tego wymaga nasz projekt, a dodatkowo wzbogacimy go o możliwość płatności poprzez najbardziej popularny na świecie system jakim jest Stripe. To jednak nie koniec ponieważ przygotowałem dla Ciebie również szereg innych ważnych zagadnień, które omówimy i wykorzystamy w praktyce.W ramach nauki skupimy się na jak najbardziej praktycznym podejściu. Zapomnij o długich i nudnych lekcjach pełnych teorii, które zapomnisz zaraz po obejrzeniu. Będziemy budować a nie debatować! W ten sposób nauczysz się pracować z edytorem Bubble na poziomie zaawansowanym. Zrozumiesz jak zabezpieczyć swoje dane przed nieuprawnionym dostępem, w jaki sposób pobierać i dynamicznie filtrować rekordy z bazy danych. A także jak wykorzystać auto-binding by móc je aktualizować bez wykorzystania skomplikowanych workflows.Dodamy do naszej aplikacji prosty komunikator, który pozwoli na wymianę wiadomości pomiędzy użytkownikami. Zadbamy również o możliwość wysyłania powiadomień mailowych poprzez zewnętrzne serwisy by ich wygląd był zgodny z naszym brandem. Nie zabraknie również takich tematów jak SSO z Google czy też proste automatyzacje z wykorzystaniem serwisu Make.
Materiał szkoleniowy został zaprojektowany tak, aby mogło z niego skorzystać jak najszersze grono odbiorców. Nieważne czy jesteś totalnym laikiem, czy też posiadasz już wiedzę z zakresu programowania lub designu, na pewno znajdziesz tu coś dla siebie. A więc kto jeszcze może skorzystać z wiedzy zawartej w tym kursie?
Zanim przejdziemy do kolejnej lekcji i wdrożymy system nadawania nowego listingu,
chciałbym zwrócić Twoją uwagę na bardzo ważny fakt, jakim są
Privacy Rules w Babel.
Obecnie jestem zalogowany jako John Wick, co zresztą widzisz tutaj na ekranie
i chciałbym podejrzeć Twój profil.
Mogę więc wybrać tutaj View Profile.
I przy okazji zauważyłem, że mamy tutaj jeszcze kilka niedoróbek.
Przede wszystkim nie mamy tutaj odstępu przy tych językach.
Tutaj imię się nie zmieniło.
Dodatkowo jeżeli sprawdzę sobie teraz URL to mam tutaj nadal Jessica Simpson.
Ponieważ do workflow, który pozwala nam edytować profil użytkownika, dodaliśmy
kroku, który aktualizuje również jego Slack.
A więc może zajmijmy się tymi poprawkami, zanim porozmawiamy sobie o rewizji Rules.
Wracam więc do edytora, przechodzę na stronę profilowania.
I tak to nie będzie Cameron, tylko oczywiście.
Karen Page.
User first name Tutaj, gdzie mamy listę, kto ma tekst,
dajemy przecinek oraz spację. I to wszystko.
Klikam sobie Close i teraz jeszcze muszę wrócić do naszego workflow.
Przejdźmy tutaj do Edit Profile.
Mamy Save button i tak zmieniliśmy tutaj dane naszego użytkownika.
Musimy więc również zaktualizować jego slug.
A więc zaczynam wpisywać Slack set a Fink Slack.
Będzie to oczywiście Parent user wartość sluga.
Już wcześniej Ci pokazywałem jak to zrobić.
Będzie to pole First name input value.
I tu przy okazji chciałbym również wrócić do tematu, o którym wspominałem w jednej z
poprzednich lekcji, czyli jak poradzić sobie znakami diakrytyczne, czyli co by
się stało, gdyby użytkownik przynajmniej w języku polskim wpisał tam jakieś imię
właśnie zawierające odpowiednie znaki?
W tym przypadku musimy zastosować następujące operacje.
Przede wszystkim pobieramy sobie wartość z tego pola, czyli First input.
Kolejno zmieniamy to wszystko na lower case, czyli na małe literki.
Będzie nam dużo łatwiej z tym pracować.
I teraz możemy sobie wybrać opcję Find and replace.
Oczywiście możesz tutaj spróbować wykorzystać jakiś reg hex.
Ja nie jestem aż tak biegły w pisaniu wyrażeń regularnych,
dlatego też zastosowałem najbardziej proste podejście jakie się dało,
czyli wpisuję polski znak diakrytyczne, a następnie zamieniam go właśnie
na ten pozbawiony tych ogonków.
Klikam close i znów daję find and replace.
I w ten sposób tutaj dodajesz sobie wszystkie znaki diakrytyczne, jakie
występują w języku polskim i zamienia się właśnie na te wartości, które powinny być.
Czyli np.
ł zamieniam tutaj na L.
Powtarzam tę operację tak długo, aż właśnie tutaj uwzględnię
wszystkie te znaki.
Oczywiście na koniec musielibyśmy tutaj dodać myślnik, wstawić
wartość z pola input.
Lower case.
I niestety znowu tutaj właśnie wybrać sobie to Find and replace
fanta, replace fanta replace.
Równie dobrze mógłbym sobie tutaj uprościć życie i.
Zrobić w ten sposób.
Kopii wstawiam spacje tutaj tekst i tylko odnoszę się do.
last name i te wszystkie
find and replace fanta replace, które będę dodawał będą oczywiście zachowane.
W ten sposób możesz obsłużyć języki diakrytyczne dla dowolnego
języka, jeśli tylko będziesz w stanie wstawić odpowiednio wartość zastępczą.
A więc to już tutaj działa.
Może to uproszczenia, bo nie zostawia to wartość taka, byś mógł
potem z niej skorzystać.
W przypadku podglądu mojego edytora i żebyś wiedział jak tutaj postępować.
Skoro to mamy gotowe, to wróćmy tutaj.
Odświeżamy.
Wybierzmy edycję.
Nie chcę tutaj nic zmieniać.
Chcę tylko, aby wskoczyły mi te wartości.
John Wick i zmienił mi się slug. Klikam Save.
Teraz podgląd.
Jak widzisz, mam tutaj już właściwą wartość, czyli John Wick.
To co chcę teraz zrobić, to skopiować sobie ten URL, a następnie się wylogować.
Przechodzę na stronę logowania i teraz chcę, żebyś przeszedł pod stronę,
czyli pod ten link, który przed chwilą skopiowali, czyli na
stronę profilu Johna Wicka.
Jak widzisz jesteśmy tutaj wylogowaniu, natomiast wszystko wyświetla
się dokładnie tak jak powinno.
Ale zobacz co się stanie, jeżeli wrócimy do edytora kolejno do zakładki Data
i tutaj zakładki Privacy.
Przechodzimy do User i klikam ten checkbox.
Chcę go odznaczyć View All Fields.
Teraz przechodzimy do podglądu.
Odświeżamy.
No i stała się mega dziwna rzecz.
Wszystkie wartości, które przekazywaliśmy dynamicznie nam zniknęły.
Co więc się stało?
Czy ten checkbox, a w zasadzie jego odznaczenie, wprowadziło jakieś zmiany
w rekordzie w naszej bazie danych?
Mogę Ci udowodnić, że nie.
Wracam do edytora, a następnie do zakładki AppData.
Teraz w bazie muszę namierzyć rekord Office + gest, czyli to
jest rekord Johna Wicka.
Klikam Edytuj.
Jak widzisz, wszystkie te wartości nadal tutaj są Mamy imię,
nazwisko, mamy języki itd.
Co się więc stało?
Otóż zadziałała reguła ustawiona dla tego data type właśnie w sekcji Privacy
Rules, czyli w tej zakładce Privacy.
Ale czym tak naprawdę są te Privacy rules?
Otóż w Babel jest to zestaw reguł, które określają, kto ma dostęp do
poszczególnych danych w aplikacji.
Są one kluczowe dla zabezpieczenia prywatności użytkowników i ochrony
danych przed nieuprawnionym dostępem.
Dzięki nim można precyzyjnie kontrolować, jakie dane są widoczne i edytowalne przez
różne grupę użytkowników w zależności od ich ról i uprawnień.
Wiem, że takie wyjaśnienie niewiele Ci pewnie powiedziało, a więc
przejdźmy do praktycznych działań.
Po pierwsze możesz definiować różne reguły prywatności dla różnych danych,
czyli dla różnych data type.
Jak widzisz, mam tutaj te reguły ustawione dla data type user.
Mogę przejść dla listingu i na chwilę obecną nie mamy tutaj
żadnych reguł ustawionych.
Wróćmy jednak do usera.
Jakiś czas temu Babel domyślnie ustawiało privacy rules dla każdego
data type jaki utworzyliśmy.
Zresztą możemy do tej opcji nawet wrócić, jeżeli przejdę tutaj do Data Type
i zaznaczy sobie właśnie ten checkbox.
Przedtem on był tutaj domyślnie zaznaczony i niestety skutkowało to
pewnym zamieszaniem i problemami.
Dla tych, którzy nie wiedzieli czym są Privacy rules i jak działają.
W ten sposób Babel nie wyświetlał im danych na stronie tak jak ma to miejsce
teraz w naszym rekordem użytkownika i widziałem masę pytań z tym
związanych na różnych forach.
Bardzo często spotkałem się też z najgorszą odpowiedzią jaką można udzielić
w tej sytuacji, czyli pozbądź się Privacy rules.
A więc mając taką poradę cała masa ludzi wracała deprawacji i je usuwała.
Robiła to po prostu w ten sposób, że klikałam tutaj tą ikonkę.
Jak widzisz nie mamy teraz tutaj zdefiniowanych żadnych reguł.
Wracamy więc na stronę chwilową i zobaczmy co się tutaj stało.
Dane znów są widoczne.
Problem rozwiązany, a my możemy działać dalej.
Otóż nie, ponieważ właśnie zrobiliśmy największy błąd, jaki można zrobić Babel
Developer, czyli zapewniliśmy nieograniczony dostęp do
danych naszej aplikacji.
Mógłbyś teraz zadać rezolutnie pytanie, ale przecież już w pierwszym sprincie
tłumaczyłem, że Babel jest bardzo bezpiecznym środowiskiem i dba
o bezpieczeństwo naszych danych. W czym więc problem?
I tak po części masz rację.
Babel wdraża po swojej stronie cały szereg rozwiązań, które mają zabezpieczyć zarówno
naszą aplikację przed atakami, jak i dane, które w niej gromadzimy.
Przechodzi też regularnie.
Przechodzi też regularnie cały szereg.
Przechodzi też regularnie cały szereg testów.
Jeśli jesteś ciekawy, jakie zabezpieczenia stosują jego twórcy, to odsyłam Cię do
dokumentacji, a link będzie teraz widoczny na ekranie.
Natomiast to, że Babel dba o Twoje dane nie oznacza, że Ty nie powinieneś.
A więc zastanówmy się kto i do jakich danych powinien mieć
dostęp w naszej aplikacji.
Wracamy więc do edytora.
Przechodzimy do zakładki Data Types i zerknijmy sobie tutaj dla Data type
user Jakie mamy pola ustawione?
Tymi przepisem DIP się nie przejmujemy, ponieważ one są do wyrzucenia.
Natomiast zerknijmy na pozostałe pola.
Pole About oczywiście powinien zobaczyć każdy.
Chcemy, aby użytkownik, który przejdzie na stronę profilowe innego użytkownika mógł
właśnie tutaj przeczytać te informacje o nim, jakie sam wprowadził.
Ale avatar oczywiście jak najbardziej też chcemy wyświetlać.
Podobnie zresztą z polem City, czyli z miastem, w którym mieszka dany użytkownik.
Pole Finish on boarding.
Jeżeli ja wyświetlimy, to oczywiście nic się nie stanie.
Ono użytkownikowi innemu nic tak naprawdę nie będzie mówiło.
First name jak najbardziej.
I z tym polem też się nie musimy przejmować,
że użytkownik zobaczy tam wartość.
Niewiele mu powie, ponieważ jest to pole, które wykorzystujemy tylko i
wewnętrznie w naszej aplikacji.
Mamy tutaj oczywiście listę języków.
Mamy tutaj również pole Last name.
To jak najbardziej chcemy wyświetlać.
Ja dodałem tutaj również kolejną kolumnę Listing i będzie to po prostu
lista odnosząca się do Data type. Listing.
W poprzedniej lekcji ustawialiśmy Data Type, a teraz ja rozwiązałem
go w drugą stronę. Właśnie z tym danym użytkownikiem.
Mamy tu również pola font, czyli numer użytkownika oraz pole User type.
To też gdybyśmy nawet gdzieś wyświetli innemu użytkownikowi niewiele powie,
wskaże tylko czy jest to po prostu gość, czy też host naszej aplikacji.
A więc teoretycznie wszystko jest ok.
Nie ma tu żadnych wrażliwych danych prócz moim zdaniem właśnie tego numeru telefonu,
który raczej nie powinien nigdzie wyciec poza naszą aplikację.
No ale jeżeli wrócimy sobie do strony profilowego, a więc wracamy do podglądu
i sprawdzamy całą tą stronę.
No to jak się okazuje ja tego numeru telefonu nigdzie nie wyświetlam, podobnie
zresztą jak tych pozostałych danych, czyli z brandingiem czy bez Archive.
Tego też nigdzie nie wyświetlamy.
A więc mógłbyś spokojnie powiedzieć, że nie ma najmniejszego problemu.
OK, te dane może są prywatne, ale my ich nie wyświetlamy.
Nikt nie ma do nich dostępu.
Natomiast niestety nie do końca jest to prawda.
I teraz chciałbym Cię udowodnić.
Klikam sobie tutaj na zbadaj.
Przechodzę sobie tutaj do zakładki Network.
Mam tutaj dalej ustawione Flow 3G.
Super, ponieważ chcę żeby to wszystko się powoli wczytywałem
i to co chcę teraz zrobić to odświeżyć sobie tą stronę czyli Command R.
Jak widzisz te dane mi się tutaj znowu wczytują.
Chwilę to zajmie ponieważ ustawiliśmy tutaj to slow 3G, ale to nic.
Widzisz, mamy tutaj całą listę różnych rzeczy.
Która jest ładowana właśnie przy uruchomieniu takiej strony,
ale mamy również coś super mega ważnego.
I to jest właśnie ta pozycja M Search, która odnosi się do zapytania jakie
wysłaliśmy do naszej bazy danych.
Działa to w ten sposób, że jak pamiętasz tutaj ustawiliśmy data type dla całej tej
strony i kolejno przekazywaliśmy tam dany rekord do wyświetlenia.
Babel sobie namierzył taki rekord bazy danych.
Wysłał tam zapytania w o taki rekord.
Następnie go namierzył i zwrócił go do przeglądarki użytkownika.
A tutaj po stronie frontend owej, którą widzisz tutaj po lewej stronie
przekazaliśmy te odpowiednie wartości i wyświetlamy je we właściwych miejscach.
Natomiast zobacz co się stanie, jeżeli kliknę sobie tutaj.
Przejdę tutaj do Response, powiększymy sobie tutaj to okienko
i zobacz co się dzieje.
Mamy tutaj tę odpowiedź i mamy wszystkie pola jakie przypisali
do naszego użytkownika.
A widzisz, rzeczywiście one pokrywają się z tym co mamy w bazie danych.
Jak niestety sam widzisz, mamy tutaj również pole Phone.
Mimo, że go nigdzie nie wyświetlamy, to nie zablokowaliśmy dostępu
do niego w żaden sposób.
A więc te dane wracają tutaj do przeglądarki i każdy może je podejrzeć.
A teraz wyobraź sobie, że w Twojej bazie zamieszczony jest np.
dokładny adres zamieszkania takiego użytkownika, albo też jakieś inne bardzo
wrażliwe dane, do których dostęp powinien mieć tylko ten dany użytkownik,
który Ci je przekazał.
Oraz Ty jako administrator serwisu, a Ty beztrosko ujawnia je teraz całemu
światu i każdemu, kto wie, jak je sobie sprawdzić.
Jak więc teraz naprawić nasz błąd?
Odpowiedź jest bardzo prosta, czyli dodać właściwe privacy rules.
A więc zamykamy ten podgląd.
Wracamy do edytora.
Przechodzimy do Privacy.
Klikamy tutaj na User kolejno Define Rule i teraz musimy nazwać daną regułę.
Ja zawsze dodaję przynajmniej jedną o nazwie owner.
Jak widzisz pojawiła mi się ta oraz ta domyślna.
Działa to w ten sposób.
To jest reguła, którą zaraz sobie zdefiniujemy.
A tu mamy reguły ustawione dla wszystkich pozostałych.
Czyli jeżeli coś jest tutaj niezdefiniowane, to zadziała ta reguła.
Czyli takie default dostępy, które chcemy tutaj ustawić.
A więc jak teraz zdefiniować tutaj tą regułę dla ownera?
W pierwszej kolejności muszę właśnie wpisać tą nazwę co już zrobiliśmy, a
następnie zdefiniować warunek logiczny, który musi być spełniony, aby
użytkownik miał dostęp do takich danych.
Brzmi to trochę skomplikowanie, ale w praktyce sprowadza się do tego, co
robiliśmy już wcześniej czy to w zakładce Conditions all, czy też dodając
warunki dla naszych workflow.
Mianowicie klikam sobie tutaj i definiuję właśnie taki condition.
Kolejno mówię, że this user czyli użytkownik, którego dotyczy
właśnie ten rekord w bazie danych.
Is current user.
To oznacza, że ta reguła dotyczy się właśnie ownera, czyli właściciela danych
takiego rekordu, czyli tego użytkownika. Dokładnie.
Jakie uprawnienia teraz taki owner powinien posiadać?
Przede wszystkim powinien móc wyświetlić wszystkie pola,
o ile nie masz tam jakiś pól, z których korzystasz tylko na swoje potrzeby
i nie chcesz się pokazywać.
U nas takich pól nie ma.
Właściciel takiego rekordu, czyli ten użytkownik powinien móc wyświetlić sobie
wszystkie pola jakie tam posiadamy, jakie dodaliśmy, jakie uzupełnił.
Do tych dwóch wrócimy później.
To ustawienie dotyczy się plików wgranych do takiego rekordu.
Możesz sobie oczywiście doczytać tutaj poprzez See Reference.
Jak to dokładnie działa?
Ja nie będę tego tłumaczył.
Od tego jest dokumentacja.
Możesz sobie to tam sprawdzić.
A więc teraz Owner może wyświetlać wszystkie pola, natomiast
pozostali użytkownicy przede wszystkim odznaczamy sobie to i zastanówmy
się, jakie pola powinni widzieć.
About mi ok, Avatar też ok.
City co?
Latamy gdzieś z City?
Miasto takiego użytkownika nie, ale to już od Ciebie zależy czy chcesz.
Wydaje mi się, że wyświetlanie samego miasta tak naprawdę nie zdradza
żadnych wrażliwych danych.
Finish Boarding to nas oczywiście na chwilę obecną nie interesuje.
First name jak najbardziej.
Języki last name i stringi.
Czemu nie?
To pole będzie pokazywało tylko listę ID ów, czyli listę ID rekordów listingu jakie
będą, jakie przypiszemy dla takiego użytkownika.
A więc tak naprawdę nic to komuś, kto by zobaczył takie dane nie powie,
więc możemy to zaznaczyć.
Numer telefonu oczywiście chcieliśmy zablokować user type
jak najbardziej, ponieważ tam korzystamy na stronie i wyświetlamy różny ten tekst.
Czy jest to private user query file guest?
Created date Jak najbardziej.
Modified date też może być.
Slack oczywiście email, o ile nie wyświetlamy.
Ale powiedzmy, że być może będziemy chcieli takie pole również.
To znów zależy od Ciebie.
Czy uważasz, że email jest polem wrażliwym czy też nie.
Ja uważam, że w tym przypadku nie.
A więc dokładnie te dane chcę teraz wyświetlać.
Przejdźmy do podglądu.
Odświeżamy.
I co się stało dalej?
Te dane nie wyświetlają. Dlaczego?
Zerknijmy.
Mamy tutaj Everyone else.
Chcemy pokazywać te pola.
OK, zaznaczmy.
Jeszcze sobie tutaj odświeżamy.
OK, dobra, musieliśmy zaznaczyć czas.
Do tego też jeszcze oczywiście wrócimy.
Jak widzisz teraz te wartości się odpowiednio wyświetlają, a jestem
niezalogowany użytkownikiem.
Tak naprawdę właśnie ta reguła mnie teraz dotyczy, czyli ta everyone else.
Natomiast jeżeli się zaloguję i przejdę sobie do profilu i tak jak się pokazywałem
znowu przejdę do konsoli i zerknę jakie dane wracają, to okaże
się, że mam dostęp do wszystkich pól.
Natomiast mogę Ci Cię udowodnić, że dostęp do tych pozostałych został zablokowany.
Znowu właśnie klikamy Zbadaj.
Przechodzimy do Network.
Odświeżamy.
Żeby nam się te wartości na nowo wczytałem.
Musimy chwilę poczekać, aż tutaj się załaduje to wywołanie, które
dotyczy właśnie M Search.
Jak widzisz zwracają to tylko te pola, które pozwoliliśmy użytkownikowi zobaczyć.
Natomiast chciałbym, żebyś zapamiętał jeszcze jedną bardzo ważną rzecz
Privacy rules, które ustawiamy zawsze działają na poziomie serwera.
To znaczy, że jeżeli wyślemy zapytanie do Bubble a ta bubble sprawdza sobie najpierw
prawa i virus, czyli jakie dane powinien zwrócić i dopiero właśnie to przefiltrować
i zwraca tylko to co właśnie powinien, czyli to co ustawiliśmy prawa.
Sirius czyli w tym przypadku to everyone else.
Zadziałała ta zasada i zwrócone zostały tylko te pola, które
powiedziałem, że możemy tutaj wyświetlić.
Jest to niesamowicie ważne.
W ten sposób dajemy taką właśnie dodatkową warstwę zabezpieczeń
i dostęp do naszych danych, zwłaszcza tych wrażliwych, mają tylko
te osoby, które powinny.
Czyli w tym przypadku na chwilę obecną właśnie my jako administrator
serwisu mamy dostęp do bazy danych.
Natomiast poza tym aplikacji teraz do tego pola ma dostęp tylko owner,
czyli właściciel takiego rekordu.
Mam nadzieję, że już rozumiesz jak działają Privacy Rules,
Dlaczego są tak ważne.
Dlaczego zawsze powinieneś je dodać do swojej aplikacji i nigdy nie
zostawić właśnie takiej opcji?
Public visible.
Lepiej jest właśnie zdefiniować jakąś jedną, nawet dotyczącą admina.
Mógłbyś tam dodać user admin i kolejno odpowiednio sobie
zdefiniować ten condition all i odnieść się do takiego user type.
My tego nie będziemy robić.
Ja z reguły właśnie dodaję przynajmniej to pole Owner dotyczące właściciela i tu
definiuje sobie dla wszystkich pozostałych jakie pola chce wyświetlać,
a jakie chce zablokować.
A skoro zadbaliśmy już privacy rule i dostęp do odpowiednich pól, to oczywiście
zapraszam Cię do kolejnej lekcji, w której porozmawiamy sobie o tym, czym jest
auto binding oraz jak działa to pole Find this insert.
Czyli ogólnie wyszukiwanie w Babel.