Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#6,947 6 comments 2 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
csharp
Domain
backend

Research direction

The issue does not name files or tests. Start by locating where profile properties are rendered and validated, then trace how user roles are available in those paths. Done means role rules can control visibility, editability, and required validation while leaving profile storage unchanged and preserving current behavior when no rules are set.

Written by the indexing model from the issue text.

Description

Status: New
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
Dominant language
C#
Stars
1.1k
Forks
791
Avg merge
2d 2h
Merged PRs (30d)
24

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dnnsoftware/Dnn.Platform

All issues in dnnsoftware/Dnn.Platform

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.