I would like to have around 20000 groups in my discourse instance, is this even possible and would it effect the performance of the website in any way?
2 Likes
How many users will you have?
What problem is 20,000 groups solving?
2 Likes
Here is the scenario. I am using discourse to realize a research paper discussion platform. Each paper is represented with a tag with paper id. All topics created under that tag appear on the tag page for that paper.
The problem is, I am missing the following functionality:
I have a manual approval process for paper authors for the papers uploaded to the system. I want to give them the ability to edit posts that are tagged with their paper. But I learned that it is not possible to give permissions based on tags.
Then, I got the idea of having a group per paper and the authors of a paper will belong to the same group. But I am not even sure if this fixes my problem because I am not sure how can I give ability to edit certain posts.
I would appreciate to hear if there is an elegant way of having this functionality. Thanks.
3 Likes
You want the author to be able to edit other people’s posts if it’s a response to their paper?
And you mean posts not topics?
Yes, whether a post is a response or related to their paper is currently determined by the tag.
But I can create a group per paper as well if it is going to help.
And ideally, both posts and topics should be editable
Groups are very lightweight, you can go to many thousands without problems.
Having 20k categories in the other hand will be a performance problem.
10 Likes
Posts don’t have tags, topics do.
I don’t understand why you want people to be able to edit other people’s posts. You can make them wikis, but then anyone can edit them.
Or maybe you want the user topic to be a wiki so that anyone can edit it.
I just don’t understand what the model is in which it makes sense to change someone else’s words.
2 Likes
I also started to question the merits that editing brings after considering several scenarios. However, it would be nice to have a mechanism to see whether a person replying is the author of the paper that the topic is related to and I think it is still not possible with groups.
More explicitly: Let’s say a user created a post tagging the paper with id 5. If the author of paper 5 posts a reply to that topic: The ideal functionality would be to somehow indicate (can be a flair, title, small default text ot the top of the post) that the user replying is the author for the paper being discussed.
If each paper is a topic, and you assign the topic OP to the author, it’s trivial to create a CSS rule to add some visual differentiation to replies from the OP on their further replies.
1 Like
Why not just have one topic per paper? Then there is no confusion. You wouldn’t need tags or groups.
Also, it seems that you are conflating the Discourse sense of topic (a collection of posts) and a post ( a single message by a single person that resides in a topic).
But now @falco beat me to it…
1 Like
@pfaffman @falco Technically, each paper is a tag. The reason is, a topic is not enough to have all the discussions or questions about a paper. There are many different aspects to be discussed and the main motivation of this forum is to have a single source of all discussions happened around a paper. Hence, each paper is a tag and all topics created under a paper’s tag can be seen from the page /tag/:paper_id.
Is it possible to do the css trick in this scenario? I can create an external database defining the relation between the tags and their respective “author users” if necessary.
1 Like
Yes, you could have a CSS file that would be automatically generated from parsing said database.
You could also do this all in Discourse by using a custom plugin too. It would bring an extra-field in the topic serializer for posts where the post author matches which can then be leveraged by the front-end app.
1 Like
I see, I am quite new to plugins but I will try to see what can be done. Thanks a lot for the advice!
2 Likes
So you understand that topics have tags, not posts. I think that you are using the word “post” when you mean “topic”.
I don’t think you answered this. If you don’t want people to edit other people’s posts, I don’t think you have any problem. I cannot imagine why you would want people to edit other people’s posts, but if you do, making them a wiki could be the solution.
Tagging topics that are about a particular paper with a paper’s tag (like a DOI, but I guess there might not be a DOI at this point in the paper’s life) is a great idea and you can do this right now with the API. Also, users who could edit the topic (trust_level 3, and the topic owner) can add the tag; others could flag it and ask it to be tagged (but doesn’t whoever started the topic know that it’s about the paper?).
I’m not clear what it is that you need a plugin for at this point.
Could you say something about where the performance problems would show up? I.e. is it on specific pages, or a general issue? If each category is linked to one or two groups, and the average user only has access to 10-20 categories in total, is it still an issue to have 20k categories?
For my (hypothetical) use case, it’s to allow for public topics to be discussed via group PMs. This approach could be used in a few different ways in an attempt to generate productive public discussions around polarizing topics. Essentially, discussions could be gamified by asking people to join teams (groups) related to a specific topic and then follow a set of rules to respond to the public topic as a team.
I’m prepared to deal with the UI issues that thousands of groups could create for the site’s staff. I realize this is an unexpected use case for Discourse groups, so am posting about it here just in case there are any obvious performance issues that I’m missing.
1 Like
Well, that makes more sense than I’d imaged. 
I think that there is some user-created-group feature in the pipeline, but I suspect it’s a ways out.
1 Like
That would be great, but for now it can be done with the API.
1 Like
Oooh. I’m starting to get off topic here, but you could use one of those API things that received a webhook for each new topic and then created a group for it. No plugin required. I don’t know why I hadn’t thought of having Discourse on both sides of one of those services before.
And GitHub - triggerdotdev/trigger.dev: ✨ Trigger.dev is an open-source platform that makes it easy for developers to create event-driven background tasks directly in their code. came across my desk today. It seems like you could make it do the work rather than paying one of those services. I doubt it has Discourse support out of the box, but it should be easy enough to make it work.
1 Like