Is badge-granting privilege still limited to admins? When defining a manually granted badge, it would be nice to be able to distribute the maintenance effort by naming user(s) or group(s) – beyond admins – who can grant/remove the badge for others.
For example, granting the "Release Manager" badge to anyone who tackled that role for the community is better maintained by the people involved with overseeing release management for the community than by the persons administering Discourse.
There's a dot that appears on the menu that appears to match the category colors. It appears sometimes and stays there and I'm not sure what the expected behavior is for that feature. Does anyone have any documentation on how that works?
We're a cloud subscriber, and about to go live. I wanted to send some warning to all of our new, incoming users on suggestions for preventing discourse.org emails getting stuck in their spam filters.
Does anyone have a list/block of IPs that you would suggest that need to be added to people's whitelist? I'm assuming everything comes from *@discourse.org, but also noticed some mailservers are using discourse.com?
In a server-side ruby plugin, I'm using DiscourseEvent.on("post_created") to get data on post replies. However, this is also being triggered when a person replies to a private message. Unfortunately, I can't see any attributes on the event objects that allow me to distinguish a reply to a topic from a reply in a PM conversation. The archetype property is set to "regular" in both of these cases.
Does anyone have any ideas how to distinguish a private message reply from other messages?
Wondering if you have a solution for us. Ideally, we would like users of our Community to automatically be notified (via email, and in community notifications) of new posts in the following categories:
So two questions:
We don't want them to receive emails for every new comment, just every new topic. Is there a way to set that for all users in our Community? Will adding these to 'Default Categories Tracking' do the trick?
Is there a way we can override the current settings for users? Our Community is a little over a month old, and we're wishing we set this from the beginning. They can opt-out if they wish, but it's important that they see notifications for new topics in these categories.
Discourse out of the box displays the currently logged in user avatar in the top nav, far right. Do we have the ability to move the location of that avatar to a secondary nav below the top nav? We will be building a custom header area for our Discourse installation to match our main site and our main site has the currently logged in user avatar in the secondary nav below the top nav. Thanks.
As a user who doesn't have access to our forum's settings, I was doing some testing to see if there was a cap on how many people we could add to a PM at once. I ended up adding a bunch of inactive accounts to the PM, but in the end it got pretty annoying to scroll through that list of users to get to the reply area. Here's a screenshot of how bad it got:
Of course, this extreme amount of participants is an edge case, but even with only two to three rows (6 to 11 users) participating in a PM, I can see that list getting annoying. The collapse button should hide the list of users. Currently it only toggles between condensed/expanded view for Frequent Posters.
Links category is going to be a core feature. Links category offers the ability to post a link instead of text as well as displaying the link in the topic list. I'll work together with the team for all its features. All features shall be working as original after the transition.
It adds an option in the category settings to be enabled. It stores links in the topic's custom fields. A customized composer which shows only a small input field instead of original one is used to post link topics. The digest email template is also overrided for displaying url.
The implementation of plugins overrides many spots of core model which looks quite awkward to merge directly. I believe another archetype is much promising to try in the new implementation as described here. But that should result in a lot of changes in composer model and post creator. I'd like to know whether it's the right path to go. @team
I installed Discourse in a vagrant box, with the standard networking configuration (config.vm.network :private_network, ip: "192.168.10.200").
When I connect to localhost:4000 Discourse loads just fine, but on 192.168.10.200:4000 I'm getting ERR_CONNECTION_REFUSED.
How to access Discourse on Vagrant without referring to localhost? I need Discourse to be accessible from within another Vagrant box.
Please note that there's no app.yml in the Vagrant version.
Edit: I don't need this anymore as I'm moving to a hosted environment with a real domain name and docker, but the issue still remains and I'd like how to fix it.
I've installed discourse and there is an additional system user there. It looks like it sends basic info abou the forum to every new user. Now because there is no real person associated with the account, nobody replied to the message. What is the way how to read those messages? I got there only by impersonating the system and going to it's inbox. It would be nice to be able to redirect the messages to the real user.
Would it be possible to look into why the Society for Neuroscience's email notifications stopped sending? We haven't received them in a week even though we're signed up.
When replying to a PM, the UI sends the POST request to discourse and specifies archetype=general in the form data. It should be specifying archetype=private_message.
This causes an issue with server-side plugins using DiscourseEvent.on(:post_created). When inspecting the topic data, the archetype is specified as whatever value was provided by the UI. This means that the plugin will receive an archetype of "general" instead of "private_message" and therefore cannot distinguish between the two.
Additionally, literally any value can be specified by the UI; it is not checked server side. This means that not only is the value for PM replies incorrect, but that the value can't be trusted to be accurate because it's an unchecked value from the client.
Hi, there's a bug with details-plugin: when selecting a big chunk of text separated in paragraphs, clicking the Hide Details -button causes the [details...] to be prefixed to each separate paragraph, not just the beginning (and end) of the selection.
The same bug applies to spoiler-plugin.
Location of bug
As far as I know, the problem is here (no idea how to fix):
So likely the culprit is applySurround and how it functions...
Reproduction
Write several lines of text (separate with linebreak)
Choose all the lines.
Click Hide Details.
PROFIT
Result
Summary
Lines with text
Summary
Lines with text
Summary
Lines with text
Summary
Lines with text
Summary
Lines with text
[details=Summary]Lines with text[/details]
[details=Summary]Lines with text[/details]
[details=Summary]Lines with text[/details]
[details=Summary]Lines with text[/details]
[details=Summary]Lines with text[/details]
Should result in:
Summary
Lines with text Lines with text Lines with text Lines with text Lines with text
[details=Summary]Lines with text
Lines with text
Lines with text
Lines with text
Lines with text[/details]
Hey all - We have an internal user who would like to use our version of Discourse for an internal team discussion. He wants to leverage the API with Slack for things like: * a team member can can ask a question in Slack, and have the bot search our Discourse for possible answer * Slack channel is alerted when their is a new topic in the private channel
The API works fine for searching what we have PUBLICLY exposed in Discuss, but we can't get the API to work for anything that is private (and so requires authentication).
I gave him the API key from Admin --> API, and we tried to authenticate with both his and my credentials. Neither gave him access to that category. It is different from other categories only in that it is available only to certain users (one group) and that it is suppressed from the home page.
Can you give me some guidance? As the site moderator, I just can't find the place where you would do this from the admin interface.
I know that Discourse setup provides sane defaults for most occasions nowadays, but I still want to ask some guidance on optimal settings. It seems that we will get a hosting partner that provides us with the server and what is on the table is this VPS:
6x vCore CPUs (Xeons @ 2.40GHz, I beleive)
8GB of RAM
My primary goal is to tweak the settings for maximum capability of handling traffic spikes, ie. concurrent users. How would you experts set the number of unicorns and the size of the database buffer?
