2016-11-16 07:56:03 +09:00
---
2016-03-13 04:47:22 +09:00
en :
simple_form :
2016-12-23 08:04:52 +09:00
hints :
2019-09-20 03:58:19 +09:00
account_alias :
acct : Specify the username@domain of the account you want to move from
account_migration :
acct : Specify the username@domain of the account you want to move to
Add moderation warnings (#9519)
* Add moderation warnings
Replace individual routes for disabling, silencing, and suspending
a user, as well as the report update route, with a unified account
action controller that allows you to select an action (none,
disable, silence, suspend) as well as whether it should generate an
e-mail notification with optional custom text. That notification,
with the optional custom text, is saved as a warning.
Additionally, there are warning presets you can configure to save
time when performing the above.
* Use Account#local_username_and_domain
2018-12-23 04:02:09 +09:00
account_warning_preset :
2021-04-22 10:25:04 +09:00
text : You can use post syntax, such as URLs, hashtags and mentions
2020-03-13 01:57:59 +09:00
title : Optional. Not visible to the recipient
Add moderation warnings (#9519)
* Add moderation warnings
Replace individual routes for disabling, silencing, and suspending
a user, as well as the report update route, with a unified account
action controller that allows you to select an action (none,
disable, silence, suspend) as well as whether it should generate an
e-mail notification with optional custom text. That notification,
with the optional custom text, is saved as a warning.
Additionally, there are warning presets you can configure to save
time when performing the above.
* Use Account#local_username_and_domain
2018-12-23 04:02:09 +09:00
admin_account_action :
2021-04-22 10:25:04 +09:00
include_statuses : The user will see which posts have caused the moderation action or warning
Add moderation warnings (#9519)
* Add moderation warnings
Replace individual routes for disabling, silencing, and suspending
a user, as well as the report update route, with a unified account
action controller that allows you to select an action (none,
disable, silence, suspend) as well as whether it should generate an
e-mail notification with optional custom text. That notification,
with the optional custom text, is saved as a warning.
Additionally, there are warning presets you can configure to save
time when performing the above.
* Use Account#local_username_and_domain
2018-12-23 04:02:09 +09:00
send_email_notification : The user will receive an explanation of what happened with their account
2021-04-22 10:25:04 +09:00
text_html : Optional. You can use post syntax. You can <a href="%{path}">add warning presets</a> to save time
Add moderation warnings (#9519)
* Add moderation warnings
Replace individual routes for disabling, silencing, and suspending
a user, as well as the report update route, with a unified account
action controller that allows you to select an action (none,
disable, silence, suspend) as well as whether it should generate an
e-mail notification with optional custom text. That notification,
with the optional custom text, is saved as a warning.
Additionally, there are warning presets you can configure to save
time when performing the above.
* Use Account#local_username_and_domain
2018-12-23 04:02:09 +09:00
type_html : Choose what to do with <strong>%{acct}</strong>
2021-02-25 00:53:16 +09:00
types :
disable : Prevent the user from using their account, but do not delete or hide their contents.
none : Use this to send a warning to the user, without triggering any other action.
sensitive : Force all this user's media attachments to be flagged as sensitive.
silence : Prevent the user from being able to post with public visibility, hide their posts and notifications from people not following them.
suspend : Prevent any interaction from or to this account and delete its contents. Revertible within 30 days.
Add moderation warnings (#9519)
* Add moderation warnings
Replace individual routes for disabling, silencing, and suspending
a user, as well as the report update route, with a unified account
action controller that allows you to select an action (none,
disable, silence, suspend) as well as whether it should generate an
e-mail notification with optional custom text. That notification,
with the optional custom text, is saved as a warning.
Additionally, there are warning presets you can configure to save
time when performing the above.
* Use Account#local_username_and_domain
2018-12-23 04:02:09 +09:00
warning_preset_id : Optional. You can still add custom text to end of the preset
2020-01-24 06:00:13 +09:00
announcement :
all_day : When checked, only the dates of the time range will be displayed
ends_at : Optional. Announcement will be automatically unpublished at this time
scheduled_at : Leave blank to publish the announcement immediately
starts_at : Optional. In case your announcement is bound to a specific time range
2021-04-22 10:25:04 +09:00
text : You can use post syntax. Please be mindful of the space the announcement will take up on the user's screen
2022-02-15 05:27:53 +09:00
appeal :
text : You can only appeal a strike once
2016-12-23 08:04:52 +09:00
defaults :
2018-06-16 01:00:23 +09:00
autofollow : People who sign up through the invite will automatically follow you
2018-07-29 09:57:13 +09:00
avatar : PNG, GIF or JPG. At most %{size}. Will be downscaled to %{dimensions}px
2021-04-15 23:28:20 +09:00
bot : Signal to others that the account mainly performs automated actions and might not be monitored
2018-06-29 22:34:36 +09:00
context : One or multiple contexts where the filter should apply
2019-09-20 03:58:19 +09:00
current_password : For security purposes please enter the password of the current account
current_username : To confirm, please enter the username of the current account
2018-01-15 12:34:28 +09:00
digest : Only sent after a long period of inactivity and only if you have received any personal messages in your absence
2022-03-07 17:36:47 +09:00
discoverable : Allow your account to be discovered by strangers through recommendations, trends and other features
2018-09-18 23:45:58 +09:00
email : You will be sent a confirmation e-mail
2018-04-14 19:41:08 +09:00
fields : You can have up to 4 items displayed as a table on your profile
2018-07-29 09:57:13 +09:00
header : PNG, GIF or JPG. At most %{size}. Will be downscaled to %{dimensions}px
2018-07-13 09:16:06 +09:00
inbox_url : Copy the URL from the frontpage of the relay you want to use
2021-04-22 10:25:04 +09:00
irreversible : Filtered posts will disappear irreversibly, even if filter is later removed
2018-06-18 01:57:31 +09:00
locale : The language of the user interface, e-mails and push notifications
2021-04-15 23:28:20 +09:00
locked : Manually control who can follow you by approving follow requests
2018-09-18 23:45:58 +09:00
password : Use at least 8 characters
2021-04-22 10:25:04 +09:00
phrase : Will be matched regardless of casing in text or content warning of a post
2018-07-06 01:31:35 +09:00
scopes : Which APIs the application will be allowed to access. If you select a top-level scope, you don't need to select individual ones.
2021-04-22 10:25:04 +09:00
setting_aggregate_reblogs : Do not show new boosts for posts that have been recently boosted (only affects newly-received boosts)
2022-04-09 01:03:31 +09:00
setting_always_send_emails : Normally e-mail notifications won't be sent when you are actively using Mastodon
2019-06-07 10:39:24 +09:00
setting_default_sensitive : Sensitive media is hidden by default and can be revealed with a click
2018-09-25 12:09:35 +09:00
setting_display_media_default : Hide media marked as sensitive
2020-03-09 00:08:38 +09:00
setting_display_media_hide_all : Always hide media
setting_display_media_show_all : Always show media
2021-04-15 23:28:20 +09:00
setting_hide_network : Who you follow and who follows you will be hidden on your profile
2021-05-18 05:31:35 +09:00
setting_noindex : Affects your public profile and post pages
2021-04-22 10:25:04 +09:00
setting_show_application : The application you use to post will be displayed in the detailed view of your posts
2019-06-27 02:33:04 +09:00
setting_use_blurhash : Gradients are based on the colors of the hidden visuals but obfuscate any details
2019-07-16 13:30:47 +09:00
setting_use_pending_items : Hide timeline updates behind a click instead of automatically scrolling the feed
2018-09-18 23:45:58 +09:00
username : Your username will be unique on %{domain}
2018-07-13 00:58:26 +09:00
whole_word : When the keyword or phrase is alphanumeric only, it will only be applied if it matches the whole word
2019-07-30 18:10:46 +09:00
domain_allow :
domain : This domain will be able to fetch data from this server and incoming data from it will be processed and stored
2020-03-13 06:35:20 +09:00
email_domain_block :
2022-02-25 01:28:23 +09:00
domain : This can be the domain name that shows up in the e-mail address or the MX record it uses. They will be checked upon sign-up.
2020-07-01 18:34:19 +09:00
with_dns_records : An attempt to resolve the given domain's DNS records will be made and the results will also be blocked
2019-02-04 12:25:59 +09:00
featured_tag :
name : 'You might want to use one of these:'
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 16:42:13 +09:00
filters :
action : Chose which action to perform when a post matches the filter
actions :
hide : Completely hide the filtered content, behaving as if it did not exist
warn : Hide the filtered content behind a warning mentioning the filter's title
2019-09-18 23:37:27 +09:00
form_challenge :
current_password : You are entering a secure area
2017-03-31 02:42:33 +09:00
imports :
2019-02-06 03:11:24 +09:00
data : CSV file exported from another Mastodon server
2019-04-09 23:06:30 +09:00
invite_request :
text : This will help us review your application
2020-10-12 23:33:49 +09:00
ip_block :
comment : Optional. Remember why you added this rule.
expires_in : IP addresses are a finite resource, they are sometimes shared and often change hands. For this reason, indefinite IP blocks are not recommended.
ip : Enter an IPv4 or IPv6 address. You can block entire ranges using the CIDR syntax. Be careful not to lock yourself out!
severities :
no_access : Block access to all resources
2022-08-25 02:00:37 +09:00
sign_up_block : New sign-ups will not be possible
2020-10-12 23:33:49 +09:00
sign_up_requires_approval : New sign-ups will require your approval
severity : Choose what will happen with requests from this IP
2021-02-22 03:50:12 +09:00
rule :
text : Describe a rule or requirement for users on this server. Try to keep it short and simple
2017-04-15 20:26:03 +09:00
sessions :
2018-05-06 17:52:36 +09:00
otp : 'Enter the two-factor code generated by your phone app or use one of your recovery codes:'
Add WebAuthn as an alternative 2FA method (#14466)
* feat: add possibility of adding WebAuthn security keys to use as 2FA
This adds a basic UI for enabling WebAuthn 2FA. We did a little refactor
to the Settings page for editing the 2FA methods – now it will list the
methods that are available to the user (TOTP and WebAuthn) and from
there they'll be able to add or remove any of them.
Also, it's worth mentioning that for enabling WebAuthn it's required to
have TOTP enabled, so the first time that you go to the 2FA Settings
page, you'll be asked to set it up.
This work was inspired by the one donde by Github in their platform, and
despite it could be approached in different ways, we decided to go with
this one given that we feel that this gives a great UX.
Co-authored-by: Facundo Padula <facundo.padula@cedarcode.com>
* feat: add request for WebAuthn as second factor at login if enabled
This commits adds the feature for using WebAuthn as a second factor for
login when enabled.
If users have WebAuthn enabled, now a page requesting for the use of a
WebAuthn credential for log in will appear, although a link redirecting
to the old page for logging in using a two-factor code will also be
present.
Co-authored-by: Facundo Padula <facundo.padula@cedarcode.com>
* feat: add possibility of deleting WebAuthn Credentials
Co-authored-by: Facundo Padula <facundo.padula@cedarcode.com>
* feat: disable WebAuthn when an Admin disables 2FA for a user
Co-authored-by: Facundo Padula <facundo.padula@cedarcode.com>
* feat: remove ability to disable TOTP leaving only WebAuthn as 2FA
Following examples form other platforms like Github, we decided to make
Webauthn 2FA secondary to 2FA with TOTP, so that we removed the
possibility of removing TOTP authentication only, leaving users with
just WEbAuthn as 2FA. Instead, users will have to click on 'Disable 2FA'
in order to remove second factor auth.
The reason for WebAuthn being secondary to TOPT is that in that way,
users will still be able to log in using their code from their phone's
application if they don't have their security keys with them – or maybe
even lost them.
* We had to change a little the flow for setting up TOTP, given that now
it's possible to setting up again if you already had TOTP, in order to
let users modify their authenticator app – given that now it's not
possible for them to disable TOTP and set it up again with another
authenticator app.
So, basically, now instead of storing the new `otp_secret` in the
user, we store it in the session until the process of set up is
finished.
This was because, as it was before, when users clicked on 'Edit' in
the new two-factor methods lists page, but then went back without
finishing the flow, their `otp_secret` had been changed therefore
invalidating their previous authenticator app, making them unable to
log in again using TOTP.
Co-authored-by: Facundo Padula <facundo.padula@cedarcode.com>
* refactor: fix eslint errors
The PR build was failing given that linting returning some errors.
This commit attempts to fix them.
* refactor: normalize i18n translations
The build was failing given that i18n translations files were not
normalized.
This commits fixes that.
* refactor: avoid having the webauthn gem locked to a specific version
* refactor: use symbols for routes without '/'
* refactor: avoid sending webauthn disabled email when 2FA is disabled
When an admins disable 2FA for users, we were sending two mails
to them, one notifying that 2FA was disabled and the other to notify
that WebAuthn was disabled.
As the second one is redundant since the first email includes it, we can
remove it and send just one email to users.
* refactor: avoid creating new env variable for webauthn_origin config
* refactor: improve flash error messages for webauthn pages
Co-authored-by: Facundo Padula <facundo.padula@cedarcode.com>
2020-08-24 23:46:27 +09:00
webauthn : If it's an USB key be sure to insert it and, if necessary, tap it.
2019-08-06 02:54:29 +09:00
tag :
name : You can only change the casing of the letters, for example, to make it more readable
2017-05-02 00:42:13 +09:00
user :
2021-04-22 10:25:04 +09:00
chosen_languages : When checked, only posts in selected languages will be displayed in public timelines
2022-07-05 09:41:40 +09:00
role : The role controls which permissions the user has
user_role :
color : Color to be used for the role throughout the UI, as RGB in hex format
highlighted : This makes the role publicly visible
name : Public name of the role, if role is set to be displayed as a badge
permissions_as_keys : Users with this role will have access to...
2022-07-09 05:39:17 +09:00
position : Higher role decides conflict resolution in certain situations. Certain actions can only be performed on roles with a lower priority
2022-06-10 04:57:36 +09:00
webhook :
events : Select events to send
url : Where events will be sent to
2016-11-16 07:02:57 +09:00
labels :
2018-04-14 19:41:08 +09:00
account :
fields :
name : Label
value : Content
2019-09-20 03:58:19 +09:00
account_alias :
acct : Handle of the old account
account_migration :
acct : Handle of the new account
Add moderation warnings (#9519)
* Add moderation warnings
Replace individual routes for disabling, silencing, and suspending
a user, as well as the report update route, with a unified account
action controller that allows you to select an action (none,
disable, silence, suspend) as well as whether it should generate an
e-mail notification with optional custom text. That notification,
with the optional custom text, is saved as a warning.
Additionally, there are warning presets you can configure to save
time when performing the above.
* Use Account#local_username_and_domain
2018-12-23 04:02:09 +09:00
account_warning_preset :
text : Preset text
2020-03-13 01:57:59 +09:00
title : Title
Add moderation warnings (#9519)
* Add moderation warnings
Replace individual routes for disabling, silencing, and suspending
a user, as well as the report update route, with a unified account
action controller that allows you to select an action (none,
disable, silence, suspend) as well as whether it should generate an
e-mail notification with optional custom text. That notification,
with the optional custom text, is saved as a warning.
Additionally, there are warning presets you can configure to save
time when performing the above.
* Use Account#local_username_and_domain
2018-12-23 04:02:09 +09:00
admin_account_action :
2021-04-22 10:25:04 +09:00
include_statuses : Include reported posts in the e-mail
Add moderation warnings (#9519)
* Add moderation warnings
Replace individual routes for disabling, silencing, and suspending
a user, as well as the report update route, with a unified account
action controller that allows you to select an action (none,
disable, silence, suspend) as well as whether it should generate an
e-mail notification with optional custom text. That notification,
with the optional custom text, is saved as a warning.
Additionally, there are warning presets you can configure to save
time when performing the above.
* Use Account#local_username_and_domain
2018-12-23 04:02:09 +09:00
send_email_notification : Notify the user per e-mail
text : Custom warning
type : Action
types :
2020-09-15 21:37:58 +09:00
disable : Freeze
none : Send a warning
2020-11-05 04:45:01 +09:00
sensitive : Sensitive
2020-09-15 21:37:58 +09:00
silence : Limit
suspend : Suspend
Add moderation warnings (#9519)
* Add moderation warnings
Replace individual routes for disabling, silencing, and suspending
a user, as well as the report update route, with a unified account
action controller that allows you to select an action (none,
disable, silence, suspend) as well as whether it should generate an
e-mail notification with optional custom text. That notification,
with the optional custom text, is saved as a warning.
Additionally, there are warning presets you can configure to save
time when performing the above.
* Use Account#local_username_and_domain
2018-12-23 04:02:09 +09:00
warning_preset_id : Use a warning preset
2020-01-24 06:00:13 +09:00
announcement :
all_day : All-day event
ends_at : End of event
scheduled_at : Schedule publication
2020-01-30 02:39:44 +09:00
starts_at : Start of event
2020-01-24 06:00:13 +09:00
text : Announcement
2022-02-15 05:27:53 +09:00
appeal :
text : Explain why this decision should be reversed
2016-11-16 07:02:57 +09:00
defaults :
2018-06-16 01:00:23 +09:00
autofollow : Invite to follow your account
2016-11-16 07:56:03 +09:00
avatar : Avatar
2018-05-07 16:31:07 +09:00
bot : This is a bot account
2018-06-17 20:54:02 +09:00
chosen_languages : Filter languages
2016-11-16 07:02:57 +09:00
confirm_new_password : Confirm new password
2016-11-16 07:56:03 +09:00
confirm_password : Confirm password
2018-06-29 22:34:36 +09:00
context : Filter contexts
2016-11-16 07:02:57 +09:00
current_password : Current password
2017-03-31 02:42:33 +09:00
data : Data
2021-04-15 23:28:20 +09:00
discoverable : Suggest account to others
2016-11-16 07:02:57 +09:00
display_name : Display name
2016-11-16 07:56:03 +09:00
email : E-mail address
2017-11-28 00:07:59 +09:00
expires_in : Expire after
2018-04-14 19:41:08 +09:00
fields : Profile metadata
2016-11-16 07:02:57 +09:00
header : Header
2020-12-10 14:27:26 +09:00
honeypot : "%{label} (do not fill in)"
2018-07-13 09:16:06 +09:00
inbox_url : URL of the relay inbox
2018-06-29 22:34:36 +09:00
irreversible : Drop instead of hide
2018-06-17 20:54:02 +09:00
locale : Interface language
2021-04-15 23:28:20 +09:00
locked : Require follow requests
2017-11-28 00:07:59 +09:00
max_uses : Max number of uses
2016-11-16 07:56:03 +09:00
new_password : New password
note : Bio
2017-01-29 04:43:38 +09:00
otp_attempt : Two-factor code
2016-11-16 07:56:03 +09:00
password : Password
2018-06-29 22:34:36 +09:00
phrase : Keyword or phrase
2019-05-26 04:27:00 +09:00
setting_advanced_layout : Enable advanced web interface
2018-12-09 21:03:01 +09:00
setting_aggregate_reblogs : Group boosts in timelines
2022-04-09 01:03:31 +09:00
setting_always_send_emails : Always send e-mail notifications
2017-04-17 19:14:03 +09:00
setting_auto_play_gif : Auto-play animated GIFs
2017-04-14 02:18:32 +09:00
setting_boost_modal : Show confirmation dialog before boosting
2021-04-22 10:25:04 +09:00
setting_crop_images : Crop images in non-expanded posts to 16x9
2018-06-18 01:57:31 +09:00
setting_default_language : Posting language
2019-06-07 10:39:24 +09:00
setting_default_privacy : Posting privacy
2017-07-10 21:00:32 +09:00
setting_default_sensitive : Always mark media as sensitive
2021-04-22 10:25:04 +09:00
setting_delete_modal : Show confirmation dialog before deleting a post
2020-10-01 02:31:03 +09:00
setting_disable_swiping : Disable swiping motions
2018-09-25 12:09:35 +09:00
setting_display_media : Media display
setting_display_media_default : Default
setting_display_media_hide_all : Hide all
setting_display_media_show_all : Show all
2021-04-22 10:25:04 +09:00
setting_expand_spoilers : Always expand posts marked with content warnings
2021-04-15 23:28:20 +09:00
setting_hide_network : Hide your social graph
2017-07-23 08:14:57 +09:00
setting_noindex : Opt-out of search engine indexing
2017-10-16 21:09:51 +09:00
setting_reduce_motion : Reduce motion in animations
2021-04-22 10:25:04 +09:00
setting_show_application : Disclose application used to send posts
2017-07-07 05:39:56 +09:00
setting_system_font_ui : Use system's default font
2017-10-01 17:52:39 +09:00
setting_theme : Site theme
2019-08-07 00:57:52 +09:00
setting_trends : Show today's trends
2017-09-21 02:41:35 +09:00
setting_unfollow_modal : Show confirmation dialog before unfollowing someone
2019-06-27 02:33:04 +09:00
setting_use_blurhash : Show colorful gradients for hidden media
2019-07-16 13:30:47 +09:00
setting_use_pending_items : Slow mode
2017-04-14 04:49:07 +09:00
severity : Severity
2020-06-09 17:23:06 +09:00
sign_in_token_attempt : Security code
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 16:42:13 +09:00
title : Title
2017-03-31 02:42:33 +09:00
type : Import type
2016-11-22 19:34:36 +09:00
username : Username
2018-02-02 18:18:55 +09:00
username_or_email : Username or Email
2018-07-13 00:58:26 +09:00
whole_word : Whole word
2020-03-13 06:35:20 +09:00
email_domain_block :
with_dns_records : Include MX records and IPs of the domain
2019-02-04 12:25:59 +09:00
featured_tag :
name : Hashtag
Revamp post filtering system (#18058)
* Add model for custom filter keywords
* Use CustomFilterKeyword internally
Does not change the API
* Fix /filters/edit and /filters/new
* Add migration tests
* Remove whole_word column from custom_filters (covered by custom_filter_keywords)
* Redesign /filters
Instead of a list, present a card that displays more information and handles
multiple keywords per filter.
* Redesign /filters/new and /filters/edit to add and remove keywords
This adds a new gem dependency: cocoon, as well as a npm dependency:
cocoon-js-vanilla. Those are used to easily populate and remove form fields
from the user interface when manipulating multiple keyword filters at once.
* Add /api/v2/filters to edit filter with multiple keywords
Entities:
- `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context`
`keywords`
- `FilterKeyword`: `id`, `keyword`, `whole_word`
API endpoits:
- `GET /api/v2/filters` to list filters (including keywords)
- `POST /api/v2/filters` to create a new filter
`keywords_attributes` can also be passed to create keywords in one request
- `GET /api/v2/filters/:id` to read a particular filter
- `PUT /api/v2/filters/:id` to update a new filter
`keywords_attributes` can also be passed to edit, delete or add keywords in
one request
- `DELETE /api/v2/filters/:id` to delete a particular filter
- `GET /api/v2/filters/:id/keywords` to list keywords for a filter
- `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a
filter
- `GET /api/v2/filter_keywords/:id` to read a particular keyword
- `PUT /api/v2/filter_keywords/:id` to edit a particular keyword
- `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword
* Change from `irreversible` boolean to `action` enum
* Remove irrelevent `irreversible_must_be_within_context` check
* Fix /filters/new and /filters/edit with update for filter_action
* Fix Rubocop/Codeclimate complaining about task names
* Refactor FeedManager#phrase_filtered?
This moves regexp building and filter caching to the `CustomFilter` class.
This does not change the functional behavior yet, but this changes how the
cache is built, doing per-custom_filter regexps so that filters can be matched
independently, while still offering caching.
* Perform server-side filtering and output result in REST API
* Fix numerous filters_changed events being sent when editing multiple keywords at once
* Add some tests
* Use the new API in the WebUI
- use client-side logic for filters we have fetched rules for.
This is so that filter changes can be retroactively applied without
reloading the UI.
- use server-side logic for filters we haven't fetched rules for yet
(e.g. network error, or initial timeline loading)
* Minor optimizations and refactoring
* Perform server-side filtering on the streaming server
* Change the wording of filter action labels
* Fix issues pointed out by linter
* Change design of “Show anyway” link in accordence to review comments
* Drop “irreversible” filtering behavior
* Move /api/v2/filter_keywords to /api/v1/filters/keywords
* Rename `filter_results` attribute to `filtered`
* Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer
* Fix systemChannelId value in streaming server
* Simplify code by removing client-side filtering code
The simplifcation comes at a cost though: filters aren't retroactively
applied anymore.
2022-06-28 16:42:13 +09:00
filters :
actions :
hide : Hide completely
warn : Hide with a warning
2016-11-25 21:15:07 +09:00
interactions :
must_be_follower : Block notifications from non-followers
must_be_following : Block notifications from people you don't follow
2017-11-15 05:12:57 +09:00
must_be_following_dm : Block direct messages from people you don't follow
2019-09-16 21:27:29 +09:00
invite :
comment : Comment
2019-04-09 23:06:30 +09:00
invite_request :
text : Why do you want to join?
2020-10-12 23:33:49 +09:00
ip_block :
comment : Comment
ip : IP
severities :
no_access : Block access
2022-08-25 02:00:37 +09:00
sign_up_block : Block sign-ups
2020-10-12 23:33:49 +09:00
sign_up_requires_approval : Limit sign-ups
severity : Rule
2016-11-16 07:02:57 +09:00
notification_emails :
2022-02-15 05:27:53 +09:00
appeal : Someone appeals a moderator decision
2017-03-20 04:29:41 +09:00
digest : Send digest e-mails
2021-05-18 05:31:35 +09:00
favourite : Someone favourited your post
2020-01-17 18:53:53 +09:00
follow : Someone followed you
follow_request : Someone requested to follow you
mention : Someone mentioned you
pending_account : New account needs review
2021-05-18 05:31:35 +09:00
reblog : Someone boosted your post
2022-02-15 05:27:53 +09:00
report : New report is submitted
trending_tag : New trend requires review
2021-02-22 03:50:12 +09:00
rule :
text : Rule
2019-08-06 02:54:29 +09:00
tag :
2021-05-07 21:33:43 +09:00
listable : Allow this hashtag to appear in searches and suggestions
2019-08-25 23:22:20 +09:00
name : Hashtag
2019-08-06 02:54:29 +09:00
trendable : Allow this hashtag to appear under trends
2021-04-22 10:25:04 +09:00
usable : Allow posts to use this hashtag
2022-07-05 09:41:40 +09:00
user :
role : Role
user_role :
color : Badge color
highlighted : Display role as badge on user profiles
name : Name
permissions_as_keys : Permissions
position : Priority
2022-06-10 04:57:36 +09:00
webhook :
events : Enabled events
url : Endpoint URL
2016-11-16 07:56:03 +09:00
'no' : 'No'
2022-08-28 11:00:39 +09:00
not_recommended : Not recommended
2019-06-07 10:39:24 +09:00
recommended : Recommended
2016-11-16 07:56:03 +09:00
required :
mark : "*"
text : required
Add WebAuthn as an alternative 2FA method (#14466)
* feat: add possibility of adding WebAuthn security keys to use as 2FA
This adds a basic UI for enabling WebAuthn 2FA. We did a little refactor
to the Settings page for editing the 2FA methods – now it will list the
methods that are available to the user (TOTP and WebAuthn) and from
there they'll be able to add or remove any of them.
Also, it's worth mentioning that for enabling WebAuthn it's required to
have TOTP enabled, so the first time that you go to the 2FA Settings
page, you'll be asked to set it up.
This work was inspired by the one donde by Github in their platform, and
despite it could be approached in different ways, we decided to go with
this one given that we feel that this gives a great UX.
Co-authored-by: Facundo Padula <facundo.padula@cedarcode.com>
* feat: add request for WebAuthn as second factor at login if enabled
This commits adds the feature for using WebAuthn as a second factor for
login when enabled.
If users have WebAuthn enabled, now a page requesting for the use of a
WebAuthn credential for log in will appear, although a link redirecting
to the old page for logging in using a two-factor code will also be
present.
Co-authored-by: Facundo Padula <facundo.padula@cedarcode.com>
* feat: add possibility of deleting WebAuthn Credentials
Co-authored-by: Facundo Padula <facundo.padula@cedarcode.com>
* feat: disable WebAuthn when an Admin disables 2FA for a user
Co-authored-by: Facundo Padula <facundo.padula@cedarcode.com>
* feat: remove ability to disable TOTP leaving only WebAuthn as 2FA
Following examples form other platforms like Github, we decided to make
Webauthn 2FA secondary to 2FA with TOTP, so that we removed the
possibility of removing TOTP authentication only, leaving users with
just WEbAuthn as 2FA. Instead, users will have to click on 'Disable 2FA'
in order to remove second factor auth.
The reason for WebAuthn being secondary to TOPT is that in that way,
users will still be able to log in using their code from their phone's
application if they don't have their security keys with them – or maybe
even lost them.
* We had to change a little the flow for setting up TOTP, given that now
it's possible to setting up again if you already had TOTP, in order to
let users modify their authenticator app – given that now it's not
possible for them to disable TOTP and set it up again with another
authenticator app.
So, basically, now instead of storing the new `otp_secret` in the
user, we store it in the session until the process of set up is
finished.
This was because, as it was before, when users clicked on 'Edit' in
the new two-factor methods lists page, but then went back without
finishing the flow, their `otp_secret` had been changed therefore
invalidating their previous authenticator app, making them unable to
log in again using TOTP.
Co-authored-by: Facundo Padula <facundo.padula@cedarcode.com>
* refactor: fix eslint errors
The PR build was failing given that linting returning some errors.
This commit attempts to fix them.
* refactor: normalize i18n translations
The build was failing given that i18n translations files were not
normalized.
This commits fixes that.
* refactor: avoid having the webauthn gem locked to a specific version
* refactor: use symbols for routes without '/'
* refactor: avoid sending webauthn disabled email when 2FA is disabled
When an admins disable 2FA for users, we were sending two mails
to them, one notifying that 2FA was disabled and the other to notify
that WebAuthn was disabled.
As the second one is redundant since the first email includes it, we can
remove it and send just one email to users.
* refactor: avoid creating new env variable for webauthn_origin config
* refactor: improve flash error messages for webauthn pages
Co-authored-by: Facundo Padula <facundo.padula@cedarcode.com>
2020-08-24 23:46:27 +09:00
title :
sessions :
webauthn : Use one of your security keys to sign in
2016-11-16 07:56:03 +09:00
'yes' : 'Yes'
