Sets loose objects from conditional views when relation is removed before new one added


This one creates friction when handling tags / status in sets: When having multiple views filtered by status, you lose an object from that view if you remove the old status by hitting delete on keyboard before adding the new status. Of course the better solution is to directly choose the new status. This works fine but I mean sometime you also do it the other way. With tags it’s even more complicated since you can have multiple tags but only one status. So if you loose the object from the view you have to go back to the “All” view and put in the new value there. I think this deserves a more convenient way.


  1. Have a set with multiple conditional views
  2. Edit tag or status by deleting the value
  3. Dont close the prompt and put in new value
  4. See that after clicking new option, you already lost object from that view if the condition is accordingly
  5. I was able to provide you a video capture of the bug, here it is:


Object should not be removed from view while editor prompt is open. After prompt is closed, conditions must be applied of course. But currently they are applied before edit prompt is closed.


  • OS:
    MacOS Ventura 13.2.1
  • Device:
    MacBook Pro M1
  • Anytype Version:
1 Like

Hi @jannis, thanks for posting! Could you check whether the issue you experience is a specific example of the issue as described here?

If so, I would suggest we either close your topic, or merge it into the one I linked above :slight_smile:

Hey @sambouwer ! Realtime refresh is not really what I am missing here. Still, the other topic seems similar to this one. I think once sets get another round of polishing, those could be both addressed. But I am not sure I really understood the other report: First they talk about missing realtime refresh but then about delay to avoid instant refresh (?). I think I am missing something :thinking:

Anyways, to make it clear: My problem is that sets with conditional views instantly apply changes of tags. It would indeed make sense to introduce a delay or even wait as long as the edit prompt is not closed. Especially when having multiple tags in a field, you would want to delete a few of them and then add new ones. For multi-condition views this won’t work really without switching back to the “All” view and editing there. But again, my problem is not that the views are missing realtime refresh. They are basically refreshing to quickly.

Hope that makes sense. Should we still merge? :slight_smile:

1 Like

Hi @jannis, thanks for your clarification. Let’s leave them separate for now. Your point is very clear, and although I think there is at least some overlap with the other topic, they are now linked anyway. That should be enough to get the message to the devs, and that is the main point of the forum! :smiley:


This report has been added to our issue tracker and received by the Development Team.

1 Like

Can’t consider this fully fixed by now, but maybe Product / Design Team needs to give opinion as you might not consider it a bug anymore.

To be on the same page here: I have a conditional set view which is created based on the status. Now there are 3 ways to change the status

  1. Change by clicking at a new status. This works fine for me.
  2. Change by clearing the current status first using the x symbol at the right, then selecting the new status. Works fine as well for me.
  3. Change by clearing the current status using the backspace key on keyboard. This does not work as intended for me because i instantly loose an object from the set view cause it no longer meets the condition.

If this was unclear, please tell and i can do a screen recording. But i think the scenario 3 should also work. :eyes:

Not reproducible anymore on Windows 11 @ v0.38.6 alpha.