[Enhancement]: Support role-based rules for profile field rendering

[uzmannazari]

Is there an existing issue for this?

• I have searched the existing issues

Description of problem

In portals with multiple user roles, different roles often require different profile fields.
Today, DNN profile properties are defined at portal level and are always shown to all users, regardless of their role.

This leads to several issues:

• Profile forms become cluttered with irrelevant fields
• Some fields are only meaningful for specific roles (e.g. vendors, staff, instructors)
• There is no built-in way to control visibility, editability, or required state of profile properties per role
• Site owners are forced to implement workarounds or build custom modules for role-specific data

Description of solution

Introduce role-based visibility and editability rules for profile properties, without changing the existing profile data schema.

Each profile property could optionally define:

• Which roles can view the field
• Which roles can edit the field
• Which roles require the field (validation)

Key points:

• Profile properties remain portal-wide
• User profile storage remains unchanged
• If no role rules are defined, behavior stays exactly as it is today
• Rules would only affect UI rendering and validation logic

This keeps the feature fully backward compatible while enabling much more flexible profile experiences.

Description of alternatives considered

1. Role-specific profile schemas:
   Rejected due to high complexity, database changes, and backward compatibility risks.

2. Separate custom modules per role:
   Works, but duplicates functionality already handled by DNN profiles and increases maintenance cost.

3. Doing nothing / workarounds:
   Leads to poor UX and inconsistent implementations across portals.

The proposed approach offers the best balance between flexibility and stability.

Anything else?

This feature would be especially useful for:

• E-commerce portals (customers vs vendors)
• Educational platforms (students vs instructors)
• Corporate portals (employees vs managers)

It also aligns well with DNN’s extensibility goals while keeping the core simple and stable.

Do you plan to contribute code for this enhancement?

• Yes

Would you be interested in sponsoring this enhancement?

• Yes

Code of Conduct

• I agree to follow this project's Code of Conduct

[uzmannazari]

@bdukes @valadas @mitchelsellers
Would love to get your thoughts on this issue. Thanks

[valadas]

It is not something I really need but if someone contributes it, I'll review and test it. The only concern is breaking changes, so the existing APIs need to probably return all fields and we could have new APIs to return them by role or something like that, but we need to make sure we don't break existing implementations and usages of profile properties.

[mitchelsellers]

I think this would be a good addition, I would want to see the proposed layout as there are already a few areas of the DNN Profile that don't do well. Especially around performance for large user bases, or installations with a lot of profile properties.

I would be slightly concerned about performance impacts, but more concerned about how to do this without introducing major breaking changes to the APIs

[uzmannazari]

Mr @valadas and Mr @mitchelsellers Thank you both for sharing your thoughts — your concerns around performance and potential breaking changes are completely understandable and very valid.

I’m willing to invest the time to properly evaluate what it would take to add this capability in a safe and flexible way. As part of that effort, all existing usages and references to the current Profile-related APIs would need to be carefully reviewed, and adjusted where necessary, to ensure existing implementations continue to work as expected.

From an implementation perspective, enabling this kind of role-based behavior would likely require introducing an additional column on the ProfilePropertyDefinition table to store role-related rules or metadata. The goal would be to keep existing APIs intact (returning all properties as they do today) while potentially introducing new, opt-in APIs or UI logic where role-based filtering is required.

I’d be very interested in your feedback on this approach, and whether you see any concerns or alternative directions worth considering before moving forward.

[mitchelsellers]

@uzmannazari I think if you wanted to prepare a high-level draft of the changes that you would anticipate, DB, API structures, behaviors I think this would be great.

As this will have far reaching impacts

• Profile Page
• User Admin (In the Persona Bar)
• API for third-party usage of the fields - I think this is going to be the "most unique" to actually enforce security while keeping with the API

I'm sure there are more, but those are the big ones righ tnow.

[uzmannazari]

@mitchelsellers Thanks for your thoughtful feedback and for outlining the key areas we need to consider. I will put together a high‑level draft of the anticipated changes, including:

• Database alterations or additions.
• Updates to API structures and expected behaviors.
• How these changes would surface in the Profile page, User Admin (Persona Bar) and third‑party consumption of profile fields.

Given how far‑reaching this feature is, your input will be invaluable in ensuring it’s implemented safely and without breaking existing functionality. I’m more than happy to collaborate closely on this and will be counting on your guidance as the draft takes shape. Thanks again for your willingness to review and help!