Add editing for published statuses #17320
Conversation
Gargron
force-pushed
the
feature-status-edit
branch
2 times, most recently
from
3127e64 to
c415357
Compare
Gargron
force-pushed
the
feature-status-edit-authoring
branch
6 times, most recently
from
0c47d59 to
7d37447
Compare
![codeclimate[bot]](https://avatars.githubusercontent.com/in/9403?s=60&v=4){kind=small}
Gargron
force-pushed
the
feature-status-edit-authoring
branch
5 times, most recently
from
70bb16d to
0cf16d1
Compare
|
Updated. |
Gargron
force-pushed
the
feature-status-edit-authoring
branch
3 times, most recently
from
8236095 to
55bef46
Compare
Gargron
force-pushed
the
feature-status-edit-authoring
branch
from
55bef46 to
47299c1
Compare
Gargron
force-pushed
the
feature-status-edit-authoring
branch
from
47299c1 to
7b9c5ac
Compare
There was a problem hiding this comment.
I'm fine with most of the changes, except with the media edit flow. I don't think it's good, neither for authors (who risk accidentally publishing changes without committing to save them) or consumers (which may lack the information something was updated). The more I think about it, the more I think it should be atomic somehow.
Otherwise the changes seem pretty solid to me. But I would not want the UI or API to be actually accessible yet, as support for receiving edited toots is not completely ironed out yet and hasn't been pushed to any release. It makes perfect sense for most of the backend changes (with their tests) to be merged in, though, but I'm less sure about UI changes (which do not have tests). In any case, I think the routes, MediaController, and status menu item changes should not be merged yet.
| # votes, so we need to remove them | ||
| if @options[:poll][:options] != poll.options || ActiveModel::Type::Boolean.new.cast(@options[:poll][:multiple]) != poll.multiple | ||
| @poll_changed = true | ||
| poll.votes.delete_all unless poll.new_record? |
There was a problem hiding this comment.
Just noticed this, but I think the cached tallies are not reset, which they definitely need to be, here.
| # This media attachment could have been detached, or the user might | ||
| # have updated the status already, in which case we don't need to | ||
| # do anything | ||
| return if @status.nil? || @status.edited_at > updated_at.to_datetime |
There was a problem hiding this comment.
If the text gets edited within the 5 minutes timeframe (without changing media ids), will the media change be recorded? I'm under the impression it will not.
| # If the media attachment being updated is attached to a published | ||
| # status, then the changes need to be recorded and distributed along | ||
| # with the status, but it may be that the status is going to be updated | ||
| # along with the media attachment, so we need to debounce | ||
| if @media_attachment.status_id.present? && @media_attachment.significantly_changed? | ||
| PublishMediaAttachmentUpdateWorker.perform_in(5.minutes, @media_attachment.id, @media_attachment.updated_at) | ||
| end |
There was a problem hiding this comment.
It's an improvement over not recording changes, but I'm still uneasy with this. Even from an UX standpoint, this is weird: the changes are committed as soon as you edit the media, and even if you don't commit the overall change. Maybe this should be queued on the client-side and submitted at the same time as the status update.
| })); | ||
| } | ||
| }); | ||
| case COMPOSE_SET_STATUS: |
There was a problem hiding this comment.
This could/should be factored in with the REDRAFT case but it's ok.
| it 'does not queue an update worker' do | ||
| expect(PublishMediaAttachmentUpdateWorker).to_not have_received(:perform_in) | ||
| end | ||
|
|
||
| it 'returns http not found' do | ||
| put :update, params: { id: media.id, description: 'Lorem ipsum!!!' } | ||
| expect(response).to have_http_status(:not_found) | ||
| context 'when already attached to a status' do | ||
| let(:status) { Fabricate(:status, account: user.account) } | ||
|
|
||
| it 'queues an update worker' do | ||
| expect(PublishMediaAttachmentUpdateWorker).to have_received(:perform_in) |
There was a problem hiding this comment.
Need to be reverted since the corresponding changes have been reverted.
Gargron
force-pushed
the
feature-status-edit-authoring
branch
from
a5e3191 to
929b67c
Compare
* Add editing for published statuses * Fix change of multiple-choice boolean in poll not resetting votes * Remove the ability to update existing media attachments for now
* Add editing for published statuses * Fix change of multiple-choice boolean in poll not resetting votes * Remove the ability to update existing media attachments for now
* Add editing for published statuses * Fix change of multiple-choice boolean in poll not resetting votes * Remove the ability to update existing media attachments for now
Follow-up to #16697
Through the REST API, a status can be updated using
status,spoiler_text,sensitive,media_idsandpollparams. If a poll is provided with different options, the votes are reset.Does not remove the "Delete & redraft" option from the UI.
Funded through the BMBF (BMBF Förderkennzeichen: 01IS21S29)