This is a feature we see wth Salesforce's Chatter (which I loathe, but have to use from time to time). Basically, full names are included with @clay type mentions by using brackets.
I think the same feature would be really useful for Discourse, potentially as a setting that can be turned on and off by admins. With it on, using @clay would expand in the text to something like @[Clay Heaton].
In our environment, in particular, given that all of the other tools that we use will convert somebody's username into their full name, it's a little jarring to see Discourse posts with just @usernames everywhere, and have to think for a minute about who the people are.
I have enabled SSO for our Discourse installation, and everything works just fine. However, when a user views their preferences, their name isn't displayed:
As you can see from this screenshot, username and email are displayed, and the users name is displayed in the header, but not in the Name section, as you'd expect.
Is this expected behavior?
I have checked, and name is populated in users, as is external_name in single_sign_on_records.
Also, is there any way to hide the "(optional)" text, as it feels very redundant here since a users full name is provided by the SSO provider, and we don't allow them to change it via Discourse.
On Slack, discussions are separated into different channels. This shares many of the same problems as groups in email - it’s not clear which channels exist, which ones are still active, and where a particular discussion should take place.
On Discourse, discussions will be visible to everyone so it doesn’t matter as much which category you choose when a topic is created. And if it seems like a topic should later be moved to another category, it’s easy to do so.
Keeping discussions focused
On Slack, discussions can get interwoven when there are multiple conversations happening at the same time. This makes them difficult to follow at best, but also puts a cap on the number of topics that can be discussed at any one time.
On Discourse, each topic has its own thread. Any number of topics can be discussed simultaneously. There may be some natural segues in and out of tangents, but indicators and the ability to quote other posts in-line help to show the flow of a discussion in a way that makes it easy to follow.
Discussions can evolve over a longer period of time
On Slack, discussions are pretty much over when they scroll off the page. WIthout that context, restarting a discussion that took place a few days ago is difficult, let alone a few months ago.
On Discourse, it is easy to continue discussions over any period of time. New members can even pick up on a conversation that was started by a someone who is no longer with the community. Indicators show when there are large gaps in time between posts to help make it clear when this takes place.
When would Slack still be preferred?
For getting ‘Quick Answers’
On Slack, discussions benefit from the high-frequency model of group chat, where each participant can help navigate with clarifying questions and responses. It serves as a great tool in this regard for getting a “quick answer” from the collective intelligence in the channel.
How can Slack and Discourse benefit each other?
There is a natural flow between Chat on Slack and Discussion on Discourse
Discourse and Slack can work well together though. The answers to a quick question may be an existing post on Discourse someone can link to.
A discussion that starts on Slack may generate deeper thoughts better expressed in a long-form medium like Discourse. After authoring a post on Discourse, a link can be dropped in the right Slack channel to inform people.
These are just some of my thoughts on how the different kinds of communication that take place on Discourse and Slack - and how both platforms can be leveraged by a single community.
@sam when I go into a randomized topic, it has a 1/5 chance that it will freeze-but it isn't frozen completely.
The first post that I come up on turns the light blue, and it stays that way until I completely close out of it. I can move the screen up and down, but I can't touch any buttons.
This doesn't happen in all topics (it's kind of randomized), but I've had to close out of Safari a couple times today due to it.
I am a discourse newb and I'm trying to get a version up and running.
I want to control the exact version which is being run, so I don't want to just pull "master" every time I install somewhere or another dev on my team installs.
In github, I see there are different branches with names like "stable" and "1.3.2" and "beta", but then there are tags that are "1.4.5", "1.5.0beta", etc.
If I want to start with a uniform environment on my team, what version is the current stable, non beta version? Should I just grab tag "1.4.5" or the "stable" branch?
Additionally: When I look at the "/admin/upgrade" for my current install, I see "discourse (e953c1c)", which I assume is the last checkin hash from git?
In the latest version of Discourse, the username and timestamp is closer to the top border of posts than the avatar, making them misaligned. The read marker is as before and thus also misaligned.
The bottom buttons in posts are 15 px from the bottom border. Avatar is 15 px from the top border.
I can only imagine this being unintentional, and you're probably already aware of it. Didn't know what to search for, so I apologise if already reported.
I am trying to figure out how to change the name of a user field from user_field_1 to something actually meaningful. I have seen that you can "register" custom fields in the after_initialize block, like so
after_initialize do
User.register_custom_field_type('a_custom_field', :text)
end
Yet this isn't actually creating the custom field on the signup page. I have not been able to find any docs for plugins here, so I'm left with asking how to do this. Is it possible?
edit: looking at some of the other posts it looks like register_custom_field_type isn't actually for registering a sign up field. Is there any way of renaming the name of a custom user field or registering a user field programatically in order to have a human understandable name?
Is there no way to do this without using the password reset email? People are used to the pattern of being able to change their password from within this account.
If not, why this deviation from the established pattern?
The main reason this is a problem is that the initial login is very confusing, people don't know they need to change their password or they get impatient and send a second reset that invalidates the first and that also confuses people.
So, I'm having an issue with my forum's letter avatars. I'm currently using larger than normal avatars for topics via this bit of code in </head>:
<script type='text/x-handlebars' data-template-name='post/poster-avatar.raw'>
{{!-- Script: replace user avatar with 70px version --}}
<a href="{{post.usernameUrl}}" classNames="trigger-user-card {{classNames}}" data-user-card="{{post.username}}">{{avatar post imageSize="70"}}</a>
</script>
With the "avatar sizes" setting in admin/settings/files updated to include 70, this has been working without issue for quite a while now (6+ months), but new users aren't getting the size 70 avatars generated now. I just noticed this today, but we don't have a frequent new users so I'm not certain how long this has been an issue.
When you click on that link, it says "an unhandled lowlevel error occured. The application logs may have details." But that appears to just be what it says whenever you swap the avatar size at the end of the url with anything not available by default (e.g., switch 70.png to 60.png and it works, switch it to 86.png and the same error pops up). So the letter avatar is properly generated every except here, I can see the new user's avatar in the Latest listing, on their profile, etc, but not on a topic page where I use the size 70 avatar.
There are no errors in /logs or on sidekiq.
Let me know if there is any more information I could provide or steps I could try to solve this issue. Thanks!
After a user has initiated the process of changing their email address, it would be helpful if there was some indication of that fact to the admins, even before the email change is confirmed.
Presumably the old address should be deactivated as well? I've made a case for that in this separate thread.
I have S3 daily backups set up, with a limit of 7 backups. Each backup is about 225MB these days.
Today I apparently ran into a disk full (though 25GB on Linode, not 10GB) situation. Leaving how that happened aside for now, should the Logs tab under Backup (/admin/backups/logs) show something if backups couldn't be created? Right now it's empty, and backups have been missing for 2-3 days:
I set up "reply via email" following these instructions:
When I post a topic in the forum, and someone replies, I get an email. When I reply to that email, the email is received in the email account that is connected with the forum. However, my reply was not posted on the thread on the forum.
Hi as more than a few of you moderate online forums you might be interested in this new set of guidelines developed by the NSPA in the UK to help forum managers and moderators respond to suicidal content and help people get the support they need.
I've had to create a mods policy on how to handle this kind of thing so I know how useful it is to have something to work from rather than creating something from scratch.
Feel free to pass it around as that's what it's there for and do throw them some feedback if you find it useful.
For many people throughout the world, income levels are a barrier to internet access. Unless individuals use free or cheap products they won't be able to gain the benefits of the technology revolution.
Allow people to participate in a Discourse forum while using a cheap phone with the lowest possible data costs. The user should be able to browse the site and decide to reply to a topic, or to create a new topic in a chosen category. This should be possible without ever having to visit the javascript version of the site.
Possible solution:
Enabling html mode
Html mode could be enabled on a forum by having the administrator provide a subdomain to access it on. For example, if the main forum is accessed at forum.example.com, the html version could be accessed through basic.forum.example.com. When a request is made through the subdomain, a different layout and some slightly altered view files could be used. A starting point for developing this could be to not include any of the Discourse javascript or stylesheets.
Replying to a topic
Instead of having a 'Reply' button, there could be an email address input, and a button that asks the user to 'Join' the conversation. Entering an email address and clicking the button would stage the user if they were new to the forum, and send the user an email to which they could respond to join the conversation. From that point on, the user could participate in that particular topic entirely through email. If they wished to see the entire thread of the conversation, or join a new topic, the could navigate back to the website.
Creating a topic
Clicking a 'Create Topic' button in the header could open a form that asks the user to choose a category and supply a topic title and their email address. Clicking a 'Send Email' button on that form would stage the user's account if it didn't already exist, and send the user an email to which they could reply to create the topic. Having done that, they could participate in the topic entirely through email.
The view
Use a simple, one column view that is designed to collapse the width of a mobile phone.
Javascript and css
The site could use a minimal amount of javascript and css for progressive enhancement. This could be used to:
hide/show forms to clean up the UI
preload pages for faster loading
The site should function well with javascript enabled and be usable on devices with limited support for css.
Visiting the main forum
To log into the main, javascript enabled, Discourse forum, the the staged user should be requested to supply a username and a password to go along with their email address.
Use case
A hypothetical use case is a forum for translating Persian text into European languages. Users who wish to have text translated can create a topic on a Discourse forum. Translators in Afghanistan can browse the forum in html mode on their phones. When they see a topic that they wish to translate they can join the conversation by email. Ideally, multiple translators will work on each topic. When agreement is reached between the translators and the client that the text is properly translated some money can be sent to pay for the work.
