Relevant figma: https://www.figma.com/design/IfwWOjzoyjQP6pnfezZa0q/Mint-and-Burn?node-id=2-14&t=9IxHSRJZMasAKbar-1

@dillchen @sssssabinaaa I had question regarding this ticket in the figma design what does these represent are they the roles like admin , moderator, member.

@dillchen @Israellund Would you like assistance in deciding how to approach this.

1. Existing Functionality:

   • On the Admin and Moderator page, you can select an address and assign it a role: Admin, Moderator, or Member.
   • A user can have multiple addresses, and if any one of their addresses is an Admin of a community, the Admin tag is shown for that user.
   • The roles (Admin, Moderator, Member) are currently handled at the address level in both the database schema and the backend logic.
   • A user is considered an Admin of a community in FE if any of their addresses has the Admin role for that community.

2. New UI Table Requirement:

   • In the new UI, a user’s address is displayed next to their name in the table.
   • This means the same user might appear multiple times in the table if they have multiple addresses with roles in the community.

3. Questions to Address:

   • Should we continue handling roles (Admin, Moderator, Member) at the address level?
   • Is it acceptable for the same user to appear multiple times in the table with different addresses?
   • Allow the selection of a specific address in a modal (popup) but omit the address in the main table.

4. Decision Needed:

   • Should we keep the roles at the address level or migrate them to the user level?
   • Should the new table allow duplication of the same user with different addresses, or should we consolidate this information?

Should we keep the roles at the address level or migrate them to the user level?

The platform answer (backend/DB) is that yes we should (keep roles on Addresses). Addresses represent membership in a community. Adding roles on user model means we would need to have an array of community ids the user is an admin/moderator of and this array would not have a foreign key constraint to the Communities table.

As for how it is displayed, I leave that to @dillchen.

Should the new table allow duplication of the same user with different addresses, or should we consolidate this information?

We should merge the display for a User, they should only show up once within the table, they may have multiple addresses that each address should show up once then from there, we should all the roles that the user's addresses have Admin | Mod | Other Group Roles

how all address compressed like this, and then from there adjust 2 things:

1. How Roles are Grouped -- proposal to show Role Name Dot Short Address

2. How Onchain Permissions are managed

-- proposal to show a row of Role Name Dot Short Address for each potential role held within the modal

@dillchen So regarding the display on the table we can like display multiple addresses against the user like this

But when it comes to assigning the role to an address how would it look like

how the address is assigned to the role here.

Per message

How Onchain Permissions are managed
-- proposal to show a row of Role Name Dot Short Address for each potential role held within the modal

Example if user has two addresses and two possible roles

Show
[address A * role A]
[address A * role B]
[address B * role A]
[address B * role B]

probably best to divide this into something with sections

So

Addresss A

• role A
• Role b

Address B

• role a
• role b

@dillchen is this correct?