Closed ctnadovich closed 10 months ago
Do you think that all of the users in a region should be able to edit all of the events in that region? or is there "ownership" of an event by a user? I'd recommend simplicity (all users can edit all events in the region).
This is a good question. The way we've done it at PA Rando is to just have one RBA who is the only person who creates/schedules events. Then organizers are assigned events that they can manage. But it doesn't really have to be that way. It could be set up so all the organizers for a region have total power over the region. Maybe that's best. As you say, it's simplest.
So if everyone associated with a region has full RBA power over that region, how does the second RBA get added? I can think of a few ways. The simplest is probably just to let the second person sign up like the first person did, with no authentication. An alternative would be to allow the existing RBA(s) to add/invite/authorize/approve a new RBA somehow.
Maybe they need to know a "secret" for their region, established by one of the others.
On Fri, Sep 29, 2023 at 10:23 PM ctnadovich @.***> wrote:
So if everyone associated with a region has full RBA power over that region, how does the second RBA get added? I can think of a few ways. The simplest is probably just to let the second person sign up like the first person did, with no authentication. An alternative would be to allow the existing RBA(s) to add/invite/authorize/approve a new RBA somehow.
— Reply to this email directly, view it on GitHub https://github.com/ctnadovich/randowizard/issues/1#issuecomment-1741633377, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACTVT7AOVIK7OS3UP6UUBLX457BDANCNFSM6AAAAAA5NEIVQE . You are receiving this because you commented.Message ID: @.***>
-- -- Sean
Interesting idea. An invitation code. When signing up to be organizer for a region, if there's already an RBA, you need this secret invitation code given to you by an existing RBA. Sure. That would work.
The database infrastructure to support multiple RBAs has been added. Still todo is a scheme for adding/removing a second RBA in a region.
Multiple RBAs for one region are now possible. The user form for a region allows an existing RBA to add another. All RBAS have equal power, including the ability to delete other RBAs.
Note that there's a subtle exception to this. It's not possible to AUTOMATICALLY add to region 1 as an RBA the same person (ie email address) who is also an RBA for region 2. This can be achieved manually, or worked around by using different email addresses, like second_rba@region1.org and second_rba@region2.org
I will close this issue and open a new issue for "Multiple Regions with the same RBA".
Need a concept of how this would be managed and authenticated before this can be deployed. Does the previous RBA need to approve the addition of another RBA? Or maybe there's a way for the existing RBA to invite another?
But implementation wise, it seems clear what's needed. The database design needs to be altered. It seems obvious that a many-to-many linking table is needed to relate region_id to user_id. The existing static 1-to-many relation from rba_member_id in the region table would be replaced.