really edit notes in more cases - fixes #424
What does this PR do?
With these changes, we actually edit notes in more cases.
Before this, changing visibility did not have any effect (if we don't want to allow editing visibility, we need to disable the drop-down in the editing window in the frontend!)
Also, changing attachments did not have any effect, either. Adding a check that oldnote.fileIds
is different from data.files.map(file => file.id)
would not be enough, because editing the alt-text of an existing attachment would still not trigger the actual editing. Determining whether alt-text has been changed is a pain (e.g. if I edit the alt-text in the Drive, then edit the note that has that file attached, I would expect the note to be re-sent with the new alt-text). Therefore, we're publishing an edit event whenever a note has attachments, even if we can't see what changed.
Contribution Guidelines By submitting this merge request, you agree to follow our Contribution Guidelines
-
I agree to follow this project's Contribution Guidelines -
I have made sure to test this pull request
Merge request reports
Activity
requested review from @fEmber, @Leah, @luna, @tess, and @supakaity
- Resolved by dakkar
Before this, changing visibility did not have any effect (if we don't want to allow editing visibility, we need to disable the drop-down in the editing window in the frontend!)
I faintly recall visibility edits causing issues some time ago which led to at least Iceshrimp (JS) and Firefish forbidding them. I don't exactly know how well they federate outwards, so it may make sense to disable it for local notes (though first testing to make sure I'm not wrong would always be great). Still, making them federate inwards would probably make sense.
Edited by S Kopper
reset approvals from @Leah by pushing to the branch
- Resolved by dakkar
mentioned in commit 58ff225c