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