Can we use a seperate table for roles?

[Manujdixit]

in my case i am integrating auth to a exisitng db, and have some restricitons.

[dosubot[bot]]

Hi @Manujdixit! I'm Dosu and I’m helping the better-auth team.

Yes, Better Auth supports using a separate table for roles and is designed to integrate flexibly with existing databases. You can configure dynamic access control so that roles and their permissions are loaded from a dedicated table (commonly named organizationRole). This allows you to define roles and permissions in your own schema, and Better Auth will query and construct role permissions at runtime based on your table structure. You can further customize behavior using options like dynamicAccessControl.enabled and hooks for role management logic (such as validation, creation, update, and deletion) source.

The framework uses adapters and plugins that can be tailored to your database setup, so you can adapt the integration to fit your schema restrictions. If you need to extend or override the schema or queries, you can do so at the adapter level source.

If you have specific schema constraints, you may need to customize the adapter or plugin configuration to match your table structure, but the system is built to support this kind of integration.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[Manujdixit]

@dosu how can i exatcly do that?

[dosubot[bot]]

You can use a separate table for roles in Better Auth by enabling dynamic access control in the organization plugin. Here’s how to set it up:

1. Enable dynamic access control by passing dynamicAccessControl: { enabled: true } to both your server and client organization plugins. You’ll also need to define an access controller (ac) that lists all possible permissions for your roles.

   // server
   organization({
     ac,
     dynamicAccessControl: { enabled: true },
   })
   // client
   organizationClient({
     dynamicAccessControl: { enabled: true },
   })

   Reference

2. Run migrations to add the organizationRole table to your database. This table will store roles and their permissions for each organization.

3. Customize the schema to match your existing table or add extra fields using the schema and additionalFields options:

   organization({
     schema: {
       organizationRole: {
         modelName: "your_roles_table", // use your table name
         fields: {
           role: "role_name_column", // map to your column names
           permission: "permissions_column",
           // ...other field mappings
         },
         additionalFields: {
           color: { type: "string", defaultValue: "#fff" },
           // ...your custom fields
         },
       },
     },
   })

   Reference

4. Manage roles at runtime using API endpoints: /organization/create-role, /organization/update-role, /organization/delete-role, /organization/list-roles, and /organization/get-role. These endpoints let you create, update, delete, and list roles dynamically, with permissions stored as JSON in your roles table.
   Reference

5. Use hooks for custom logic during role creation, updates, and member management. You can inject validation, mapping, or business rules using the organizationHooks option.
   Reference

If your schema is different from the default, you can remap table and field names or add extra fields as shown above. All DB interactions go through the adapter, so you can further customize queries if needed.

If you share your table schema or specific restrictions, I can help with a more targeted config example.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[yKriguer]

@Manujdixit did you know if we have to create a new role in an organization, and attach this role to a new member, will this role automatically get the memberAc.statements?