A client approached me with a request to create a card-based user directory.
As he’s hosted on discourse.org, I initially said this would not be possible (aside from any performance issues), as the attributes required to fill a user card are not available in the user object serialized with directory items.
However, after discussing it further, I determined that one approach could be to make a PR into core which adds user attributes to the directory item serializer via a site setting. The idea being that this functionality will be useful for various styles of user directory which require various mixtures of user attributes (example below).
Experimenting with this, I’ve come up with a relatively simple approach, which you can see on this diff:
Create a dedicated DirectoryItemUserSerializer (the current “UserSerializer” inside the DirectoryItemSerializer has always felt a bit strange to me).
If the site admin has selected any user attributes to add:
Create a serialized user to take advantage of the protections of that serializer, e.g. staff / private / untrusted attributes.
Serialize any added attributes which pass the UserSerializer filter.
The goals here being to:
Not affect the existing behviour in any way.
Serialize only those attributes requested.
If you guys are on board with this approach / request, I’ll finish this off by:
Adding a validation on the site setting (i.e. to ensure the string entered is a user attribute)
Adding tests.
However I thought it best to run this by you guys first.
Example
As an example of the kind of functionality this would allow, the screenshot below from my local just using this change to core + a theme component that overrides the existing directory and uses a modified user-card component:
I think @blake and @awesomerobot is working with another customer with similar requirements. I am kind of open for a site setting like we have always_include_topic_excerpts
Caveat is that I would like this tested and I would like the site setting to be hidden.
I know @david has been interested in the problem as well, I am a bit mixed here but maybe a longer term solution here that is cleaner is:
Add hidden site settings for “allow plugins and themes to opt for extra serialized info” default off
Then have a protocol in themes/plugins for “asking” for the extra info.
The advantage here is that some themes then will have the extra serialized info and some not.
I would like to wait on David a bit here before giving you a green light.
How about making the user directory serializer accept a new parameter like users.json?include_profile=true
Then we can add a JS plugin API which allows themes to add this parameter:
api.userListIncludeProfile(true)
“Profile” would include all the things in the regular user serializer (being careful not to introduce n+1 queries). I don’t think specifying individual fields is going to make much difference to performance, so IMO we should keep it simple.
The same approach could work for topic lists as well ?include_excerpts=true
I also like this because it means the “per-theme serializer configuration” won’t get broken by the anon cache!
Close but this does not work cleanly cause when you head to the home page of the site or to the u path you don’t have the luxury of adding a param to the path, we need defaults changed
In that case, I think a hidden site setting is a good starting point. Would be nice to make it per-theme, but we need to build some infrastructure there first. I still think a boolean “user list includes profile” setting will be easier to reason with.
Cool. Let us know if you guys consider this #pr-welcome and in what form, and we’d be happy to make one. On our end, @fzngagan is going to handle this from here.
One thing to clarify here is the protocol for requesting additional data. Can we rely on the site setting on the frontend to request the data or as you suggested, add another api in the plugin-api?
