It could be helpful to enable end-users of forums to have some say over what information is displayed on their profiles on a granular level, and to set their profile to not be indexable.
Please note I am new to Discourse/Ruby/Ember and I haven’t got much technical knowledge yet in how things work ‘under the bonnet’ so I hope this makes sense and is clear enough to explain my thoughts!
Some use cases of this are, for example, if I have a forum with a certification level custom field which is mandatory and which is set to display by global config, but some users may prefer this to be:
Private to staff only
Visible to logged in users only
Visible to certain trust levels only
Public (no change from global config)
Another example might be for health-related fields where members choose to share that information only with trusted members of the community at a certain trust level or higher, or just with the staff of the forum, and do not want their profiles to be indexed.
I would envisage this could be applied to any/all fields by having the following:
System setting to allow users to determine visibility of field/s
Field setting to prevent users overriding in the case where the admins wish to set the visibility and NOT allow overriding (or a global white-list of fields which the user can override if this is easier to manage)
Front-end profile edit field enabling the user to set the privacy level for the fields they can control in this way
Front-end themes check if the field has privacy set to show/not show when rendering profiles (could apply to cards as well?)
I think this is what was being requested in this post: Privacy settings on the user's profile page - it could also be complemented by a ‘set no-index’ flag which the user could edit if given permission to do so.
A work-around for your part of your situation would be to have a public and a private certification level field. Users could include it in the private required field and put it in the public field if they so chose. It wouldn’t be that much more difficult to enter it twice than to have a checkbox that said who could see it. That doesn’t solve the logged-in/trust level part, though.
@pfaffman thanks for chiming in and for the suggestion.
Yeah, could take that approach, but scale that to a community of thousands and that’s rather unacceptable duplication of data not to mention error prone/frustrating and like you point out, not addressing the trust level/logged in bit
Fingers crossed it might be something that would be useful and considered as a request!
For the record, I like this pattern in general and would like to see it used more widely. One example where I think this could be helpful is on the groups page for “who can message” and “who can mention” a group.
And just to reiterate, what my client needs is the ability to apply that setting per group, and not let the user decide. He wants only privileged people to be able to make their contact info (and so on) public. I think that I’ve solved that problem by hiding those fields so that users in the non-privileged group can’t set those fields (by hiding with CSS), but having it in the UX would be cleaner.
What I mean by the option regarding fields showing on profiles is that it might be globally set to show on public profiles, but allowing an option to permit users to override this and choose to hide the field and/or restrict to trust levels.
The first part (a setting to say whether users could override the global setting) would be a great start, guessing the latter (exposing trust levels and allowing the user to say which trust levels can see the fields) might be a bit more tricky to implement.
So in summary, it’s about giving administrators the opportunity to hand the user the flexibility to control the privacy of the information on their profile, on a field-by-field basis.
I see, I understand your use case here but it would be a very very complex change.
I would like to see global permissions implemented first and do not really feel the per-user permission thing is something we will be building into core any time soon (multiple years out, if ever).
I think your best bet, if you need this now, is to build a custom plugin for this.
