The default 5 minutes may add too much lag for some sites used to mailing list performance.
Unfortunately, this seems to require restarting the server for the change to be noticed - is there any way to avoid that, or otherwise should this be noted in the setting text?
Should be used whenever you activate the "download_remote_images_to_local" site setting to prevent users from receiving a lot of edit notifications from the system user.
Add a new SiteSetting to specify a maximum of items to be shown in post action menus per default. If more buttons are rendered and those after mentioned maximum will be hidden behind a collapsible ellipsis-button. Once clicked it slides in the missing buttons and hides itself.
If the setting is set to 0, the ellipsis will not be applied. It default is set to 4 though.
All buttons are created equal - but the Reply-Button is more equal than others: If it is rendered, the reply button will never be hidden behind the ellipsis. The max count is exclusiding the reply button and its position would make the reply button hide, it is removed there and pushed to the end of the list.
Feature to allow each imported post to be created using a different discourse
username. A possible use case of this is a multi-author blog where discourse
is being used to track comments. This feature allows authors to receive
updates when someone leaves a comment on one of their articles because each of
the imported posts can be created using the discourse username of the author.
Ideally it would be a menu selection to select POP3, POP3S, and potentially other future protocols like IMAP if desired, but I didn't want to deal with data migration at this point. And then I was going to have a checkbox for "Secure" (on by default, obviously), but that was very hard to word as to how it was different given everything else referred to pop3s and I couldn't change that either. So I settled on a preference:
pop3s_polling_insecure: "Poll using plain text POP3 without SSL"
Off by default.
This makes it very clear that as to what turning on that checkbox will be, and by calling it "insecure" makes sure people will think twice before turning it on.
I have not attempted to do any of the translations of the preference, I'm ot sure how you handle that.
- add site_setting choices lists to list entries
- allows for handy autocompletion using the new select2.js UI
- automatically merges plugin choices into existing list, allowing for easy extension
It adds a new setting 'email_prefix' to configure which [label] will be used in the subject of emails. Discourse currently uses '[title]'. The problem is that sometimes you need to set a longer title, that doesn't really work well for emails. I think this is very common since the HTML `<title>` tag is very important for SEO.
It will default to '[title]' if this setting is not used.
See: https://meta.discourse.org/t/where-to-change-the-email-subject-prefix/11989
The goal of this is twofold:
- Make the more commonly changed settings higher
- Find groups for more uncategorized settings
Additionally, the SEO category was deleted, its contents folded into Security and Spam.
add an external_username attribute for username from SSO payload
repair the field name in SingleSignOnRecord migration
move setting of external_username for sso to controller
add settings toggle to override username/email from SSO payload
fix changing of external username after override toggle
complete tests and logic for sso override
add some extra context to username override option
add external_email and external_name to single sign on record
add setting for name override from SSO payload
complete override with stored external_email and external_name
add missing checks to tests
remove an unneeded describe block
break up a monster method for single sign on
fixes for sso attribute override after failed tests
- allow the configuration of an inbox-email-address per category
- post emails to that email into that category instead of global
- Adds UI for configuration
- Adds Documentation for configuration
- Adds Tests for new feature
With the new email_in admin configuration setting, emails to the email_in_address fetched via POP will now be processed and posted as new topics to the forum.
With the email_in_min_trust you can control the trust level the user needs to have at least to be able to post an email as a new topic.
Also contains tests for the email-in feature and minor clean ups
