-
-
Notifications
You must be signed in to change notification settings - Fork 7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Record account suspend/silence time and keep track of domain blocks #10660
Record account suspend/silence time and keep track of domain blocks #10660
Conversation
73ce2d3
to
7b7a442
Compare
2a33831
to
91cf394
Compare
Updated. The unblock screen won't ask whether you want to unblock all existing accounts of that instance anymore, and will instead give the count of accounts that would actually be unblocked. The accounts affected are those whose block date matches that of the domain block or are |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could remove the booleans
We definitely could, I just wanted to avoid a costly and error-prone migration script.
Le 1 mai 2019 17:55:22 GMT+02:00, Eugen Rochko <notifications@github.com> a écrit :
…Gargron commented on this pull request.
We could remove the booleans
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#10660 (review)
--
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
|
I think the idea here is good but removing the boolean columns now is going to save us a ton of headaches down the road wrt our data model. If you really really don't want to remove the booleans, then we should encapsulate any logic that refers to the booleans or the dates into the account model so that we only have to care about the legacy data model in one place. |
91cf394
to
474bbfd
Compare
…ere recorded" This reverts commit a015c65.
023e3c0
to
51ea81a
Compare
I have changed the migration script to set the
|
2ec9f35
to
518b373
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First pass. I think we can narrow down the amount of files touched by this change, especially spec files as noted below. We should make sure we're using the suspend!
and silence!
methods in specs going forward.
db/post_migrate/20190511152737_remove_suspended_silenced_account_fields.rb
Show resolved
Hide resolved
5d44a17
to
e9b944e
Compare
db22b4c
to
986a4d5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
now that we can undo domain blocks precisely, is there any argument for leaving in the ability to undo them and NOT unsilence/unsuspend affected users? it seems like an extra level of complexity that doesn't help anyone
6ed0a26
to
320d417
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM % a minor question about the tests
320d417
to
7d7a58c
Compare
I think this has broken the explore page:
|
Need to tootctl cache clear |
Fix a regression from mastodon#10660
…astodon#10660) * Record account suspend/silence time and keep track of domain blocks * Also unblock users who were suspended/silenced before dates were recorded * Add tests * Keep track of suspending date for users suspended through the CLI * Show accurate number of accounts that would be affected by unsuspending an instance * Change migration to set silenced_at and suspended_at * Revert "Also unblock users who were suspended/silenced before dates were recorded" This reverts commit a015c65. * Switch from using suspended and silenced to suspended_at and silenced_at * Add post-deployment migration script to remove `suspended` and `silenced` columns * Use Account#silence! and Account#suspend! instead of updating the underlying property * Add silenced_at and suspended_at migration to post-migration * Change account fabricator to translate suspended and silenced attributes * Minor fixes * Make unblocking domains always retroactive
Fix a regression from mastodon#10660
…astodon#10660) * Record account suspend/silence time and keep track of domain blocks * Also unblock users who were suspended/silenced before dates were recorded * Add tests * Keep track of suspending date for users suspended through the CLI * Show accurate number of accounts that would be affected by unsuspending an instance * Change migration to set silenced_at and suspended_at * Revert "Also unblock users who were suspended/silenced before dates were recorded" This reverts commit a015c65. * Switch from using suspended and silenced to suspended_at and silenced_at * Add post-deployment migration script to remove `suspended` and `silenced` columns * Use Account#silence! and Account#suspend! instead of updating the underlying property * Add silenced_at and suspended_at migration to post-migration * Change account fabricator to translate suspended and silenced attributes * Minor fixes * Make unblocking domains always retroactive
…astodon#10660) * Record account suspend/silence time and keep track of domain blocks * Also unblock users who were suspended/silenced before dates were recorded * Add tests * Keep track of suspending date for users suspended through the CLI * Show accurate number of accounts that would be affected by unsuspending an instance * Change migration to set silenced_at and suspended_at * Revert "Also unblock users who were suspended/silenced before dates were recorded" This reverts commit a015c65. * Switch from using suspended and silenced to suspended_at and silenced_at * Add post-deployment migration script to remove `suspended` and `silenced` columns * Use Account#silence! and Account#suspend! instead of updating the underlying property * Add silenced_at and suspended_at migration to post-migration * Change account fabricator to translate suspended and silenced attributes * Minor fixes * Make unblocking domains always retroactive
Fix a regression from mastodon#10660
Currently, undoing an instance block will either unblock every blocked person on that instance or none (depending on the moderator's choice), because an instance block translates to an individual block for every user of that instance.
This change records the time an user was blocked, and ties the unblock part to blocks performed exactly at the same time as the instance block.
This is a work in progress because we have to figure out what to do with instances that were blocked before that PR. The code in the PR will not unblock them, which is probably not what we want to do.The proposed code will currently unblock anyone that matches the severity of the domain block and who was individually blocked before the migration was run.Also need to add tests and make sure the interface is clear.