Akihiko Odaki [Tue, 3 Oct 2017 11:10:07 +0000 (20:10 +0900)]
Remove aria-label of status content (#5195)
aria-label contained body of status with content warning, which should be
hidden by default. Remove the label for the case and other cases due to
consistency.
aschmitz [Mon, 2 Oct 2017 19:28:59 +0000 (14:28 -0500)]
Make IdsToBigints (mostly!) non-blocking (#5088)
* Make IdsToBigints (mostly!) non-blocking
This pulls in GitLab's MigrationHelpers, which include code to make
column changes in ways that Postgres can do without locking. In general,
this involves creating a new column, adding an index and any foreign
keys as appropriate, adding a trigger to keep it populated alongside
the old column, and then progressively copying data over to the new
column, before removing the old column and replacing it with the new
one.
A few changes to GitLab's MigrationHelpers were necessary:
* Some changes were made to remove dependencies on other GitLab code.
* We explicitly wait for index creation before forging ahead on column
replacements.
* We use different temporary column names, to avoid running into index
name length limits.
* We rename the generated indices back to what they "should" be after
replacing columns.
* We rename the generated foreign keys to use the new column names when
we had to create them. (This allows the migration to be rolled back
without incident.)
# Big Scary Warning
There are two things here that may trip up large instances:
1. The change for tables' "id" columns is not concurrent. In
particular, the stream_entries table may be big, and does not
concurrently migrate its id column. (On the other hand, x_id type
columns are all concurrent.)
2. This migration will take a long time to run, *but it should not
lock tables during that time* (with the exception of the "id"
columns as described above). That means this should probably be run
in `screen` or some other session that can be run for a long time.
Notably, the migration will take *longer* than it would without
these changes, but the website will still be responsive during that
time.
These changes were tested on a relatively large statuses table (256k
entries), and the service remained responsive during the migration.
Migrations both forward and backward were tested.
* Rubocop fixes
* MigrationHelpers: Support ID columns in some cases
This doesn't work in cases where the ID column is referred to as a
foreign key by another table.
* MigrationHelpers: support foreign keys for ID cols
Note that this does not yet support foreign keys on non-primary-key
columns, but Mastodon also doesn't yet have any that we've needed to
migrate.
This means we can perform fully "concurrent" migrations to change ID
column types, and the IdsToBigints migration can happen with effectively
no downtime. (A few operations require a transaction, such as renaming
columns or deleting them, but these transactions should not block for
noticeable amounts of time.)
The algorithm for generating foreign key names has changed with this,
and therefore all of those changed in schema.rb.
* Provide status, allow for interruptions
The MigrationHelpers now allow restarting the rename of a column if it
was interrupted, by removing the old "new column" and re-starting the
process.
Along with this, they now provide status updates on the changes which
are happening, as well as indications about when the changes can be
safely interrupted (when there are at least 10 seconds estimated to be
left before copying data is complete).
The IdsToBigints migration now also sorts the columns it migrates by
size, starting with the largest tables. This should provide
administrators a worst-case scenario estimate for the length of
migrations: each successive change will get faster, giving admins a
chance to abort early on if they need to run the migration later. The
idea is that this does not force them to try to time interruptions
between smaller migrations.
* Fix column sorting in IdsToBigints
Not a significant change, but it impacts the order of columns in the
database and db/schema.rb.
Eugen Rochko [Thu, 28 Sep 2017 21:20:08 +0000 (23:20 +0200)]
Change max redirects followed to 2 (#5136)
I see no reason to allow more than that. Usually a redirect is
HTTP->HTTPS, then maybe URL structure changed, but more than that
is highly unlikely to be a legitimate use case.
Eugen Rochko [Thu, 28 Sep 2017 15:50:14 +0000 (17:50 +0200)]
If HTTP signature is wrong and webfinger cache is stale, retry with resolve (#5129)
If the signature could not be verified and the webfinger of the account
was last retrieved longer than the cache period, try re-resolving the
account and then attempting to verify the signature again
Eugen Rochko [Thu, 28 Sep 2017 13:31:31 +0000 (15:31 +0200)]
Add ability to specify alternative text for media attachments (#5123)
* Fix #117 - Add ability to specify alternative text for media attachments
- POST /api/v1/media accepts `description` straight away
- PUT /api/v1/media/:id to update `description` (only for unattached ones)
- Serialized as `name` of Document object in ActivityPub
- Uploads form adjusted for better performance and description input
Eugen Rochko [Wed, 27 Sep 2017 21:42:49 +0000 (23:42 +0200)]
When OAuth password verification fails, return 401 instead of redirect (#5111)
Call to warden.authenticate! in resource_owner_from_credentials would
make the request redirect to sign-in path, which is a bad response for
apps. Now bad credentials just return nil, which leads to HTTP 401
from Doorkeeper. Also, accounts with enabled 2FA cannot be logged into
this way.
Eugen Rochko [Mon, 25 Sep 2017 22:29:29 +0000 (00:29 +0200)]
Send streaming API delete to people mentioned in status (#5103)
- Previously they wouldn't receive it unless they were author's
followers
- Skip unpush from public/hashtag timelines if status wasn't
public in the first place
Eugen Rochko [Mon, 25 Sep 2017 21:05:54 +0000 (23:05 +0200)]
New error page graphic. Other error page improvements (#5099)
- 500.html generated with admin-set default locale if set
- Error page `<title>` includes Mastodon site title
- 500 title changed to "This page is not
correct" (ref: <https://www.youtube.com/watch?v=2VCAP_seh1A>)
- 500 content appended with "on our end" to make clear it's
not user's fault
Eugen Rochko [Mon, 25 Sep 2017 16:36:33 +0000 (18:36 +0200)]
Fix emojify() by generating a mapping to existing Twemoji files (#5080)
A new rake task emojis:generate downloads a full list of valid
unicode sequences from unicode.org and checks it against existing
Twemoji files, finally generating a map from each sequence to the
existing file (e.g. when there's multiple ways an emoji can be
expressed). The map is dumped into app/javascript/mastodon/emoji_map.json
That file is loaded by emojione_light.js (now a misnomer) which
decorates it further with shortcodes taken from emoji-mart's index.
We added horizontal layout to preview card for wide image. However, max height of the thumbnail is still limited to 120px and it makes nearly square images to too small for that layout.
This PR increases max height as well as max width.
Fix shortname problem in emojify() (regression from #5016) (#5032)
When colon appears end of line, skiped all character containing unicode emojis. Fixed.
https://github.com/tootsuite/mastodon/pull/5016#issuecomment-331012008
Use file extensions in addition to MIME types for file picker (#5029)
Currently we're using a list of MIME types for `accept` attribute on `input[type="file"]` for filter options of file picker, and actual file extensions will be infered by browsers. However, infered extensions may not include our expected items. For example, "image/jpeg" seems to be infered to
only ".jfif" extension in Firefox.
To ensure common file extensions are in the list, this PR adds file extensions in addition to MIME types. Also having items in both format is encouraged by HTML5 spec.
cat aescling's git repositories / mastodon.git / log