WHAT IS THE BUG
When converting a Set into a Collection the relations are wrong. I would say so. All the objects have a IT-Tag, but i have activated a filter so not all IT-Tags should apear in the collection and so they also should not appear in the relations. And when I want to undo it with STRG + Z the Collection was now converted back to a Set but the newly created relations stay.
HOW TO REPRODUCE IT
Explanation: Collections are new. Before them I made a relation of each object to the set. That´s why the graph in the first img looks like that.
Now I want to convert the set into a collection
After that the graph changes, but now there are relations between the set and the object which should not have a relation to each outer. The outer objects which appear all have the IT-Tag, but in the collection I have this filter which excludes those. So I would say that should not happen. So maybe its a bug or just a confusing feature
Now with STRG + Z I can convert back the Collection to a Set. That´s the real bug
But the relations will stay the same, even if its now a Set again.
THE EXPECTED BEHAVIOR
- The relations after converting the Set into a Collection should change, but they should now be bidirectional in my case and only the filtered objects should have a relation to the collection.
- By using STRG + Z to “convert back” the Collection into a Set the relations should change to the old state
Windows PC and Laptop
- Anytype Version:
Hi @JulianKropp, thanks for posting! At first sight, the behavior you are seeing looks correct and expected.
In the images 7 & 8 you point to the difference between Sets (with Object type “IT”) and Collections (missing this info). Collections are not limited to a single Object Type, or a single Relation. You fully control which Objects are visible in the Collection.
The reason why (currently) the action to turn a Set into a Collection is unidirectional is that it could be too complex to come up with a query that matches the Objects you manually added to a Collection. If you add to related Objects (same type, same Relations with the same values) it might be straightforward to just create a Set of that Object type and apply the filters needed to get to only those two Objects (for example by filtering on name). If we go a step further (same type, different Relations with different values) it becomes harder, but it is still doable: you create a Set based on the Object Type and then add a filter on the name of the two Objects. Now, imagine a Collection with 1000’s of Objects, all unrelated (different Object Types, different Relations, different values for those Relations). The only way to go from a Collection back to a Set is to query on a shared Relation (because the Objects are from different Types) like “creation date” and then filter on the name of each Object, which results in many filters.
For CTRL-Z I can see the use case as Anytype still could “know” what the Set settings where before it was turned into a Collection.