default reply visibility is bugged #28

Closed
opened 2022-07-25 17:17:50 +00:00 by toast · 7 comments
Owner

My private account has "default visibility: followers" and "remembering" turned off (it does this with it on as well).
When replying to an unlisted post, it sets the visibility of my reply to unlisted.
The algorithm should be most-restrictive(your-default, replied-to-post).
I'm not sure where this is, but making this so I remember to look for it later.

My private account has "default visibility: followers" and "remembering" turned off (it does this with it on as well). When replying to an unlisted post, it sets the visibility of my reply to unlisted. The algorithm should be `most-restrictive(your-default, replied-to-post)`. I'm not sure where this is, but making this so I remember to look for it later.
toast added this to the (deleted) project 2022-07-25 17:17:50 +00:00
Owner

Maybe we should include in this that you shouldn't be able to reply with a more open scope. E.g. replying to a DM with public scope should not even be allowed by the API.

Maybe we should include in this that you shouldn't be able to reply with a more open scope. E.g. replying to a DM with public scope should not even be allowed by the API.
Owner

The API now enforces that the visibility is not more open than the replied to or quoted note. (commit 40d9aa6219)

The API now enforces that the visibility is not more open than the replied to or quoted note. (commit 40d9aa62199dc637039ee7931685195097fe5035)
Owner

In that commit I also removed some backend code that set the visibility to home when you replied to a non-public post with a public post. Maybe that is related to the weirdness experienced.

Now, the client should be changed in such a way that

  1. the respective visibility is selected automatically and
  2. the other visibilities are not even selectable.
In that commit I also removed some backend code that set the visibility to *home* when you replied to a non-*public* post with a *public* post. Maybe that is related to the weirdness experienced. Now, the **client** should be changed in such a way that 1) the respective visibility is selected automatically and 2) the other visibilities are not even selectable.
Author
Owner

I'll try and look into it asaic - but the backend enforcement is a good start!

I'll try and look into it asaic - but the backend enforcement is a good start!
Author
Owner

Ok, looks like the correct spot for this is components/post-form.vue - specifically the let visibility part.
This code is weird, so I might try and refactor it wholly after I figure out what's going on.

Ok, looks like the correct spot for this is components/post-form.vue - specifically the `let visibility` part. This code is *weird*, so I might try and refactor it wholly after I figure out what's going on.
Author
Owner

the respective visibility is selected automatically and

#67 implements this

the other visibilities are not even selectable

this is left to do

> the respective visibility is selected automatically and #67 implements this > the other visibilities are not even selectable this is left to do
Johann150 added the
fix
label 2022-12-23 10:21:50 +00:00
Johann150 removed this from the (deleted) project 2022-12-23 10:21:52 +00:00
Owner

fixed in 338e898f56

fixed in 338e898f5691532891f2229da7f4c5efd4de7598
Sign in to join this conversation.
No Label
feature
fix
upkeep
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: FoundKeyGang/FoundKey#28
No description provided.