I have a collection called ‘Events’. My employees, identified as ‘Admin’ via a true/false property, can create and edit all types of content in my app.
But I also want to let specific users create events and edit their own events.
Currently I use ‘create/edit event’ buttons to allow admins to create/edit events.
How do I also allow certain users to create any events, but only allow them to edit events they created?
Does Adalo record which user created an item?
And, if so, can I use that to let the author edit that item?
Can I use OR logic to determine the visibility of the ‘create/edit event’ button?
Or do I need to create 2 different buttons, each with its own visibility rules?
Add a many-to-one relationship for events to users. Users can own multiple events, events belong to 1 user. Your “edit” button can have a visibility setting “Current Event > User > Email” is equal to “Logged in user > Email”
Still the OR operator is not available for visibility conditions ( Hope Adalo Team will add this feature soon. Not sure if there is a workaround.). I think you need to use two icons with separate visibility conditions.
One is visible if the Logged in user>Admin ( true/false property)>is true. And other icon is visible if the Current Event > Creator’s(created one to many relationship)>email>is equal to>Logged in user’s email. And group the two icons and group the app bar and that group and set the fixed type to top of that full group.
cc: @Flawless Excellent solution from both of you!
Question: If I stack the two icons, each with its own visibility condition, what happens if I am both the Admin and the Creator? Will both icons be visible? It wouldn’t matter which one I use to edit the event, since I have edit permission either way.
I think I know the answer, so I’m asking this question in case any future reader has this same issue.
If they do both appear, I think I will position the two icons side by side, instead of stacked. The non-Admin Creator will always see only one, and it won’t matter if my Admins see both.
I answered my own question. If I am both the Admin and the Creator, both icons are visible.
This is not a problem. Both buttons are only visible if I am both roles, and so only my in-house admins will see the “ugliness”.
And one other note. The above addresses how to let a user edit his own Event, but not how to let a user create Events. So I added a CreateEditOwnEvent (true/false) property to my users collection. I then put a CreateEvent button on the EventsList screen and set its visibility to allow only a user to create an event when that property is true.
2 buttons. One button for admins, one for event creators.
On the one for admins, set the visibility to sometimes visible if logged in user > admin > is equal to > true. This part you already know.
On the button for users to edit, set the visibility to sometimes visible if Current Event > User > email > is equal to > logged in user > email. While the button is selected, group it by itself. You’ll have a group with just a button. Set this group to sometimes visible if logged in user > admin > is equal to > false.
This will display only 1 edit button based on the permission.
The logic is like this:
Are they admin?
Yes, display button one and hide the second button.
No, display button two and hide the first button.
Once it’s determined if you are or are not admin, it asks this:
Are they the owner of the event?
Yes, display the second button.
No, hide the second button.
An elegant solution! It works perfectly. I also applied @dilon_perera’s suggestion to group the two buttons together. So, with the second button also grouped by itself, I end up with a group within a group. Here’s what the screen looks like:
a) the CalendarEventView screen in the app builder
Both buttons link to the same edit screen. Admins can create, and edit, any events. And some users (those who are granted permission) can create events and edit only events they created. This will save my Admins a lot of work.
As an important side note, this may have solved the “using OR logic to determine visibility” problem. I’ll have to think about that a bit.
