Search Ideas

They could keep read-only access to the discussion but can’t add new ideas or change existing ideas.

They could keep access to their own ideas but not see others’.

There could be hard cutoff: they lose access to everything, including their own ideas in that discussion.

What happens if you add a user to a private discussion, they submit a bunch of ideas, and then you remove them?

Could this feature be unified with #2811 somehow?

Could this feature be unified with #2669 somehow?

Then people could occasionally check the second tab for ideas they think they can rationally hold but actually can’t. And then they can work on addressing criticisms. A kind of ‘mental housekeeping’ to ensure they never accidentally accept problematic ideas as true.

#3014 fixes this. Implemented as of c3247d5.

For all ideas, the total number of pending criticisms (if any) should always be shown, even if they are not all being rendered. For filtered parents, I could put an asterisk behind the count. On hover, explain that some pending criticisms may be hidden due to filtering.

As with #2098, implementing an accurate count of the number of shown criticisms gets very tricky once the user starts submitting new criticisms on filtered parents.

For filtered parents, I could put an asterisk behind the count. On hover, explain that the total number of pending criticisms may be greater on the unfiltered view.

For filtered parents, I could put an asterisk behind the count. On hover, explain that some pending criticisms may be hidden due to filtering.

For filtered parents, I could put an asterisk behind the count. On hover, explain that the total number of pending criticisms may be greater on the unfiltered view.

Still, the count is valuable in that it shows how many criticisms need to be addressed to restore an idea.

I could get rid of the count everywhere, even on unfiltered views. That would have the added benefit that users wouldn’t prefer one problematic idea over another just because it has fewer pending criticisms.

I could get rid of the count everywhere, even on unfiltered views.

The displayed criticism count for a filtered parent can differ from the number of displayed criticisms.

But users are expecting a count.

For any filtered parent, the criticism badge could be shown without a count.

For any filtered parent, the criticism badge could be shown without any count.

I have this working to the point that it shows n / m, but getting the counter to update properly when new criticisms are posted on filtered parents is surprisingly difficult – so difficult the juice may not be worth the squeeze.

Fixed as of 27123bd.

Done as of 27123bd.

Bug: as you cycle through a parent’s versions on ideas#show, the children are suddenly not being filtered anymore, and the highlighted idea suddenly has siblings.

Bug when cycling through ‘filtered’ revisions: on page render, no matter how many children/criticisms a parent of the highlighted idea has, only the highlighted idea is shown – that’s fine so far – but the displayed criticism count may be higher if there are criticisms that are not being shown. So there’s a mismatch.