Well, that’s boring – I don’t care if you are a member if you never posted. What’s the point? Like a high school yearbook that shows pictures of people who never attended a day of class?
Not all communities exist only within Discourse. And some communities are new users of Discourse with a large existing user base.
Fine, but that is not the design function of this page.
The reason is indeed this:
Hmm. So, what actually is the design function of the “user directory” then, if not to be a directory of users of the site?
I have the alternative use case:
Some public categories:
for users to introduce themselves to the community (“Newbies” category")
public “Events” categories.
Some users get to by-pass posting in the “Newbies” category if introduced by a member of the community.
Large number of non-public categories which contain the majority of content.
Would still like the “Users Directory” to display non-public activity as this community is “effectively public”, just with a optional staging area for users as a gateway to the private categories.
The larger community / activity exists in “private categories” - but the community very much sees this as public.
Yes, it does not count activity from restricted categories.
For me excluding restricted category content does not provide an accurate user directory view.
In same as removing the restricted category counts from the totals on the about page would.
Would posts from “Lounge” not be counted?
Yes it’s a restricted category. I understand the argument, but it would be very inefficient to query a version of the user directory based on who is looking at it.
That wasn’t what I was thinking.
Perhaps the notion of a “public” or “private” forum / discourse instance…
For me the existence of a users activity on a public forum instance should display publicly - there is no issue in displaying a count of posts a user has made in the “Lounge”. If these counts do not include content from “restricted categories” my users will see the user directory as very broken.
For @Sander78 however displaying / including counts from “restricted categories” rises a privacy issue and I would consider his forum instance as “private”. Actually for him I would see the trust(1) level(2) pages(3) as a further issue in terms of revealing who is using his forum privately.
I disagree. I feel that most users would see counts of their private activity (ie restricted categories) to be a privacy issue. You can imagine someone watching their directory and saying “oh wow you can see them posting a lot of restricted stuff!”
It seems much safer just to exclude it.
The issue I have is that ~90% of user activity occurs in “restricted categories” and I would like that to be seen in the Users Directory.
In my case users would say “where are my posts - I’ve posted - but my posts included in the count”.
Well, then I’m totally happy with the user page as it is now. Because it serves my client’s needs of privacy at the same time (as long as they don’t post in a public category, but that’s ok).
Not necessarily. Yes, you have to cache more, but you could cache views / likes / whatever per category, filter by current user’s access list and sum the values in Ruby code. Since a list of accessible category IDs is available in the user model anyways, that should be O(n) on number of categories, no?
This is only true due to Discourse’s binary interpretation of “public”. Any Discourse instance which’s users are predominantly members of an organization that the forum is intended to support will either appear uninviting to guests (when
login required is set, there can be no truly public content at all) or will have to have a lot of “restricted” categories which are public in practice (i.e. require TL0 to access).
That is what I have been meaning to speak about in regards to private profiles.
Either I have to completely shut off my community (private) or have restricted categories, BUT ergo, Discourse considers the latter set up ‘public’ and thus other items (such as profiles, user activity listed elsewhere or not confusing things) are still technically ‘public’ and now open for every visitor or random passerby to gawk at.
At least with SMF I could fine-tune those things so I could have some in-between state. I could have public topics/categories to whet visitor’s appetites while keeping the rest of the forum (and profiles, et al) secure.
This in-between state could also allow me to have a public category for a top-level domain blog and allow visitors to interact with blog comments via Discourse. Can’t have that with Discourse if it means giving up privacy for my userbase with their profiles and other activity, or hints of it.
EDIT: To round this to the current topic, I will say that having privacy built into the new user directory would be moot for my ‘usual/old’ set up described above. In fact, I would highly welcome all the activity front and center for public view, especially if someone registers an account to use the front-end blog and eventually apply for the actual community (which is private). That way they can see who is active, and who they can possibly PM to ask questions. With the profile privacy feature idea, clicking to a profile yields a login wall for a guest. That is fine. When they actually sign up is when they would see profiles and then they can slowly go through the motions of applying to become a member of the private community.
But closing off the entire thing like some ivory tower wouldn’t allow me to use Discourse in conjunction with a public blog. Nor would I be able to show bits and pieces of the private community with topics and member profiles once they take the plunge and log in to explore more. If it isn’t for them, they simply don’t post and delete their account or just never log in.
OK! we made some decisions on this
The user directory will now show all stats for all users no matter what category their posts are in. This is much simpler.
You can switch off user directory via a site setting if you have the sort of site where users seeing the mere presence of other users (even if they can’t see any of their posts) may cause issues. This is also simple.
I do think the underlying issues are irreconcilable, so this gives us a nice (and simple for the first version of this feature) way to allow both camps to have reasonable choices.
@eviltrout will make it so tomorrow.
(there is a more complex version of this where stats can be selected per-category but we don’t have time for that in v1.3)
Here is the functionality that @codinghorror mentioned:
The new site setting is called
I was a bit surprised to see it under
Admin -> Settings -> Users
but I guess it makes as much sense there as anywhere else.
And some of the Admin pages are getting so long adding any more “trees” to them will get them lost in the “forest”
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.