The cascade change wasn’t in the release notes. It landed as a surprise.
We shipped without asking the community first. We should have.
Collection support was bolted on last-minute before release. Not enough time for us or testers to think it through
Sorry. The trust concerns several of you raised are fair, and we’d rather own that than argue about it.
One thing worth keeping in mind
Cascade deletion moves children to the Bin - same as archiving anything yourself. Archived objects don’t show up in search, queries, or links, but they’re still there. Nothing is permanently gone until you empty the Bin.
That doesn’t make it OK, and yes, if the Bin gets noisy and someone empties it without looking, this turns destructive in practice. Fixing that is part of the plan.
What we’re doing
Hotfix on PR in anytype-heart is already merged. We are gonna release today on desktop, mobile in the next few days
Rolling back most of what 0.55.0 added:
Objects created inside other objects (via /Create object) or via collections: no more auto-archiving.
Files/images inside Collections: no more cascade either. Archiving a Collection won’t touch its members.
What we’re keeping - the pre-0.55.0 behavior that’s been around for releases without complaints:
Files/images added as blocks (drag-drop or /file into a page) still get auto-archived when the parent is archived.
Files/images set as property values (e.g. an object’s icon or cover picture) still get auto-archived together with the object.
These cases are intuitively “part of” the parent and nobody’s been surprised by them. Temporary scope reduction so we can take the time to design the rest properly. Feel free to leave feedback about this as well
Proper fix is planned in 1-3 weeks
The direction:
Confirmation dialog when you archive something with cascade-eligible children. It’ll list them — names, types, previews.
Default = keep children. You opt in to cascade, not out.
Created in context becomes a visible property. No more hidden rules.
Bin fixes - partial restore, consistent nesting, no more child-getting-sucked-back-into-parent on later restore (@n7cgu4sxyjzl’s reports).
The drag-drop-many-images case (@kaye’s example: you swap images while drafting and end up with 6 unused). Is keep-by-default still right here, or do you actually want auto-cleanup for this one?
Should the dialog remember your choice per parent type (“always cascade pages, never Collections”), or always reset to the safe default.
It’s a situation I’ve been through too (and one that others around me have experienced as well; it’s especially frustrating when you discover Anytype and end up testing more and failing more often).
I’m adding a new image (via drag-and-drop or another method). Oops, it’s the wrong one or it doesn’t fit: I need to be able to actually delete it. An object linked to a single object should be deleted when the block is deleted. Plus, a message clearly indicates that it has been moved to the trash.
While I’m all for a warning and giving users a choice when dealing with a group (since it’s less obvious), in this case it would be a hassle.
Pleaaase keep it (or add an option in settings…)
Personally, I’d like that, but I see the risk: “I never want to delete it, but once I chose to do so, it stayed that way.”
So… if it’s just the checkbox that’s checked if it was checked last time, but the warning stays visible, that seems perfectly acceptable to me for everyone.
And the example given is exactly what I’d like—I often want to delete “page + content” (common use), rarely “collection + content” (just when I’m doing a big clean-up ^^).
That said, the benefit of the pre-checked box isn’t huge; I wouldn’t make a big deal out of it if it doesn’t remember the last choice.
1.
I heard in another post that you are developing a “garbage collection” style feature to show files or documents that aren’t linked anywhere. Once this is implemented, the best approach might be to prompt users to clean up with a red dot notification when the number of unlinked files reaches a certain threshold or on a set schedule.
To answer your specific question, I think we need to distinguish between the drag-and-drop method and the /file command.
With drag-and-drop, it’s intuitive to assume the added file is strictly dependent on the document. Therefore, if the file’s block is deleted within the document, deleting the actual file feels natural. Simply showing a notification that the file was moved to the Bin at the moment of block deletion is enough. (Of course, it absolutely shouldn’t be deleted if it’s linked in other documents.)
However, using the /file command simply pulls up a file that has been added to the space, independent of the current document. It’s unclear whether the file was intended solely for this specific document. If someone uploaded a file this way intending to reuse it across multiple pages later, it would be quite frustrating if it were deleted just because it was removed from the first document it was attached to.
2.
I think it would be better for the dialog to remember the choice. It seems most convenient to provide a “Don’t ask again” checkbox in the confirmation dialog to remember how to handle specific object types. Even if the remembered choice leads to an unintended action, the items only go to the Bin anyway. As long as a notification pops up showing how many files were moved to the Bin, users will immediately realize if they made a mistake right after deletion.
However, for overly cautious users or those who might check the box by mistake, it would be great to have an option in the Settings to manage this confirmation behavior. The options could be:
Always ask
Default (respect the “Don’t ask again” choices for specific types, and ask for the rest; this also needs a button to reset remembered choices)
Thanks for the update! It’s good news, but let’s be honest: any logic that goes against “data safety by default” is toxic — if not immediately, then definitely over time.
Let me explain with a real-world example: I have three documents. In the first one, images were drag-and-dropped from my file manager. In the second, images were added from the app’s internal Gallery. The third one is a mix of both. Months later, I decide to clean up and delete some documents or blocks.
Questions for the room: What result will I get? How can I predict it in advance? Why should two identical-looking images in the same document have different lifecycles just for the sake of someone’s idea of “convenience”? We need a unified approach that guarantees data integrity across the board!
The issue of “orphan objects” should be handled separately in the Space settings. This chase after “convenience” inevitably leads us back to file management anyway. But it’s much better to manage these objects through Views/Filters than by digging through the Bin. As an idea: why not implement a Media Upload Log, similar to a browser’s download list? You could see everything you’ve added, where deleted objects are simply crossed out.
I appreciate that you have a clear stance here, but this cascading deletion system for drag n drop images on inline blocks has been in place for awhile and no users have complained about it. The likely reason is because the system is doing what users want—which also happens to be the behaviour they expect from most apps. Images in an object are typically tied to that object and don’t have alternative lives (only occasionally in Anytype).
Currently, a notification (toast) is displayed when a user deletes—they should be aware of what’s going on.
When you are in a collaborative space with many other users, a garbage collector system is not as helpful as it seems. Users typically err on the side of keep instead of delete—especially when it’s not their own creation. You also can’t expect that this ‘maintenance job’ will be undertaken by everybody, if at all. Additionally, since Anytype is local-first, this leads to space bloat that has tangible impacts on mobile devices.
A garbage collector system is a 2nd line of defence, and we shouldn’t view it as a sufficient solution—because it isn’t in many cases where a space has more than one user. We also want to explore more intuitive (seamless) solutions that don’t require additional user actions to stay organised (it’s a chore).
Because this perspective is focused on single player, it doesn’t take into account the complexities of collaborative spaces.
I wonder: would it be possible to make “smart delete” an option of the space/channel?
I have not and will not, but if there was an option to disable this “smart delete”, I would take it. (I say per space/channel, because I can see myself enabling it on specific types of spaces/channels and disabling it on others)
Anyway, other than that, just want to say thanks for the transparency and working on this. I appreciate how the team is handling this.
Take a look at this screenshot of one of my older documents. Can you tell me the fate of Image 1 versus Image 2 if I delete this document? Can you predict where Image 1 goes if I delete its specific block, and where Image 2 ends up?
NO, YOU CAN’T. And neither can anyone else.
The situation gets even worse in shared spaces. One member uploads, another deletes, and a third one manages the Bin. If, a month later, it is impossible to tell how each object was added to a document just by looking at it, you have no right to design different deletion logics for them. I will not accept any excuses about the existence of the Bin; only the items I have intentionally selected should ever end up there. You have violated fundamental software development guidelines regarding determinism and UI predictability.
As long as the issue of mixed-origin files in a single document remains unresolved, every single line of code related to linked or cascade deletion is a stab in the back to everyone who trusts you with their data.
I respect that you have a strong opinion on this, but let’s take it down a notch. We are transparently having a discussion with the community about the behaviour of an app. Let’s have it in good spirits.
We are not operating with malicious intent with the hopes that our users lose their data. There are simply different points of view. Two other users in this thread alone have already expressed that they have no problem with cascading deletion in some instances. So let’s hear what people have to say and go from there.
While I do agree with you in general, this is not the case with our community. The fact that the collection cascading deletion was complained about immediately (day after release) while the other cascading deletion of inline images was not should be a signal we can learn from. Again, I’m not saying its the right decision, but it is a signal that’s relevant.
Speaking as one of the tagged complainers, I really appreciate both @requilence’s and @kaye’s responses. Thank you for jumping on this with a short-term fix as quickly as possble, and also for committing to more long-term work on it as well.
I’m inclined toward @n7cgu4sxyjzl’s view that nothing should be binned without the user’s explicit knowledge, even these particular kinds of images that nobody had raised a flag about. Like, if people start to notice a bug only after it crosses a threshold of impactfulness, that doesn’t mean the less impactful instance of it didn’t need to be fixed too.
As I said in the other thread, all of this is outside my current use-case, so I don’t have much skin in the game as it currently stands. But as a matter of principle for future similar decisions that could impact my use, I’ll always vote for erring on the side of transparency and user control.
I agree with this statement. However, the argument that follows seems a bit too one-sided.
While some users might leave if they worry their data isn’t safe from unexpected deletion, others will leave if they find the app inconvenient, long before they even encounter such a scenario.
This is ultimately a matter of striking a balance between convenience and data stability; there is no absolute truth.
In this regard, I believe the method I suggested serves as a reasonable compromise. What do you think?
I think we should be cautious about making that assumption. There is no particular reason why this community would be fundamentally different from others. While it might seem that way right now, as the user base grows, we will eventually see the same general trends and behaviors.
First, thank you for bringing this issue forward. Being upfront is a key component in the trust one can place in a software.
Long time user here, and I did not know that. Or would I trust the way it works. Dealing with orphan objects is a real pain, so I’d make sure everything is deleted.
Does this change the way a drag’n’dropped file-block is handled when deleting the block? In the contextual menu, there’s a “Delete block” entry. Can this also delete the underlying file?
I get behind this argument. Predictability is an important part of the UX.
I believe there’s an issue in the original post, having both the term “archiving” and “deletion”. I guess those refer to the same thing: sending objects to the bin.
What I’d like is to have a confirmation dialog everytime:
Deleting a page
Deleting blocks in a page
Deleting a collection
What’s pre-selected could change. My stance would be not to use context (drag’n’drop, …) to choose what to select (I don’t believe this is deterministic enough) or not but a more simple thing: being an orphan (no more backlinks once deleted).
This list can be a tree, since we’re talking about cascading here. If there’s an image in a page B in a page A. Deleting A may offer to delete B and the associated image. I get that it can get quite tedious to have multiple levels and all (to the point that the entire space could be in the list). It’d be fine not to be able to cascade B if B is linked elsewhere.
Agree but the team has metrics that Kaye might be basing her decisions on (I remember having some cool features disabled because they weren’t “used enough” )?
And to counter the idea that “losing documents drives users away,” I’d like to point out that I’ve also experienced the situation where “the mess caused by undeleted documents drove this user away.” Ah, the art of compromise—such a skill, and so easy to forget!
It would be great if this could be customized (maybe a “Security” tab in the settings?) for each type of object, to meet everyone’s needs.
But I’d like to add one point to keep in mind: don’t forget about new users.
When deleting for the first time, display a dialog box with an option to configure this setting as the default in the settings.
Because settings are great!
But you also have to let users know they exist .
@n7cgu4sxyjzl formulates his points of view hard, but he’s IMHO right in every aspect.
The quote contains two important statements in that I subscribe:
Only the items that the user has intentionally deleted should ever end up in the bin, waiting there for the final deletion.
– I would say, if the team in addition to that also implements a cascade delete function (of course with extra security and confirmation dialogue and so on), the automatic deleted objects should end up in a separate section of the bin, so that the user can differentiate the automatic deleted Objects on one glance from his manual deleted Objects.
They shouldn’t appear mixed in one View. They should appear in separate Views.
And emptying the bin should empty only the items in the actual View.
He writes: “You have violated fundamental software development guidelines regarding determinism and UI predictability”
– In my opinion, that’s also true. Hard formulated, but sometimes it seems necessary.
A software should behave in a predictable way.
“Predictable” doesn’t mean that such things (the rules behind cascaded deletion) was once explained somewhere in a docu that the user may or may not have read.
“Predictable” does IMHO mean, that the user doesn’t need to think “what kind of potential fatal consequences could my next innocent looking mouse click maybe have?”.
He knows intuitively what his actions do and the result will not surprise him afterwards.
– Without the later regret: “Oh no, I’ve forgotten that there is a rule based logic that becomes triggered if I click on a full moon day on an Object that contains images that come from drag & drop, but not from the clipboard, and that don’t appear in any other Object!”
[Sarcasm ON]
I mean, Anytype could also have a button in the top bar that immediately wipes the user’s hard disc!
There could be a good and intelligent logic behind it (a logic that’s somewhere explained in a document somewhere on the official home page). And for some users it would spare time, compared to a manual wiping …
– I mean, imagine suddenly does the police ring the bell and you need to shredder all potential dangerous data as quick as possible!
Wouldn’t it be nice to have such a practical feature that spares so much time for the user???
A feature that thinks on its own, based on highly intelligent rules that always predict what the user just needs!
Wouldn’t it be nice to have???
– Great, implement that!!! [Sarcasm OFF}
I’m likewise a little confused about what the devs mean with different words. I’m gathering from context that “archiving” means putting in the bin, but I’m not 100% on that. Also, “deleting” apparently doesn’t mean putting in the bin, but rather emptying the bin. I think? But that doesn’t quite fit with how @requilence titled the thread, so
In my posts, I’ve used “binning” to mean the thing that’s currently happening in a cascade - certain child objects being put in the bin with parents.
Yeah, and also I wonder if the devs are experimenting with eliminating excess friction for the sake of a future larger userbase. Successful tech creators like Apple have gotten a lot of mileage out of “streamlining” options and actions because the average user doesn’t want to have to think about their tech; they just want it to do stuff quickly. This is in stark contrast to the type of person who’s attracted to AT right now (and even more so who would want to discuss it on a forum). Even a dialog asking confirmation before you bin child objects is a little more of a cognitive load to process. That sort of thing adds up. For us, it promotes a sense of trust and self-determination. For others, it could feel like a needless chore. If AT is to become financially sustainable, will it have to accommodate some degree of that “normie” sensibility? I hope not - one of the reasons I avoid Apple products is because I hate the way they funnel my usage. And an “everything app” by nature can’t be too directive with the user. But I could imagine the kind of transparency of function and fine user control that we want being a roadblock to sufficiently widespread adoption, and I sympathize with the devs if that’s the case.
Hotfix is live on desktop (v0.55.4). As promised: cascade deletion reverted for objects, and for images/files inside Collections. What’s left is the pre-existing behavior - drag-drop and /file blocks on a page, files set as icon/cover and other properties. Mobile in the next few days.
@n7cgu4sxyjzl We also shipped something that directly addresses your screenshot: Created in context is now a visible property on every object. So for those two images you posted, you can now actually see, on each one, which object it was created through (or whether it has none). The “two identical-looking images, different lifecycles” problem doesn’t go away, but the lifecycle stops being hidden.
I want to push this further though, because a property in the panel still means you have to open it to know. What I’m thinking: a small icon in the corner of an image block that tells you at a glance: “this file is linked here, lives independently” vs. “this file was created here and belongs to this object.” Same idea for objects. Would that actually help you read what’s going on, or does it still feel like
guesswork?
On the Bin.@Code-Jack’s idea of separating auto-archived from user-archived items is interesting. But if we are going to explicitly approve cascade deletion for objects, does it make sense to have it just for files? If you archive an object, you will see its files nested in the hierarchy. If you remove just the image block, then yes, you will see it hanging.
On settings (per-space, per-type, modes). I get the appeal but I’m wary. In a collaborative space, if the owner picks one mode and members expect another, you get less predictability, not more. @kaye’s collaboration point cuts both ways. I’d rather get the default flow right (explicit confirmation, visible context, clearer Bin) than ask people to configure their way to safety.
Thanks again for the active conversation here! It’s very helpful
Thank you. This patch was the first necessary step. Let’s discuss the “Created in context” property.
There is a display bug showing “No value”, even though clicking the property reveals the original note (not page). This extra click adds inconvenience to viewing the origin. Otherwise, we get a false lead.
This property, just like “Origin”, cannot be changed. An image can have a life after Drag’n’Drop. When returned to the original document, its deletion can end up in either the Bin or the Library — verified on two different documents right now. Thus, we come to the conclusion that these properties are opaque and useless. But let’s assume it’s too painful for you to roll back the absurdity of the old solution.
Right now, you are enforcing a segregation of files within a single document, dividing them into “privileged” and “disposable” ones based on their “country of origin” — in the best traditions of radical ideologues. Regarding the suggestion of a small icon in the corner — why settle for half-measures? Why not put them in a red frame with crosshairs? Better yet, slap a “TEMPORARY MEDIA FOR ONE MINUTE” watermark across the entire image! Only then will it truly be INTUITIVELY FELT that the file is a second-class citizen, already halfway to the Bin.
P.S. And honestly, if you refuse to protect drag’n’drop images from destruction, at least consider a “rehabilitation system” for these hostages in a single click. This click should wipe both “Created in context” and “Origin,” finally granting them full-fledged citizenship and a guaranteed existence within the space.
Although I agree with you, the decision of which of my files are important is mine to make, not the tool’s or an AI’s, Could you take it easy? There is no need for such “examples”.
I believe the Anytype team has already demonstrated and proven their transparency and willingness to find a good solution to this issue.
I agree with that statement. But let’s all take a step back and realise that what is ‘predictable’ is subjective to different user expectations.
For many Anytypers who are very well versed in the object based system, what should be predictable in deletion of an object is clear. I don’t question that because there are real logical arguments for it. But what is ‘predictable’ to some, does not represent the experience for everybody (or necessarily the majority).
It is objectively the case that many new users enter Anytype and expect it to be a ‘Notion alternative’—we know this statistically. When they upload an image via drag n drop into a page and delete the page, their experience teaches them that the image should be deleted with the page. This is what happens in almost every other app that they’ve ever used in their entire life. Thus, Anytype actually behaves ‘unpredictably’ to them when they find the image has not been deleted and it’s still sitting in their space. We’ve seen this feedback first hand. Heck, I’ve experienced this first hand when I used Anytype for the very first time and didn’t know about the object based system. Anytype did not behave predictably to me at all when I first came across this ‘quirk’.
I’m not arguing about which approach is truly ‘predictable’. My point is simply that the user’s experience of predictability is not singular, nor is it static.
I’d rather we move away from such hard stances of right and wrong in discussions. Let’s think of practical suggestions taking into account that there is a wide base of users for Anytype. And for the majority all new users, they’ve never used an object based system before—and teaching them all the ins and outs of object-based systems and knowledge graphs from a 20 minute tutorial is not a realistic expectation.
@kaye in principle there could be a solution that fits for everyone:
Simply put a switch into the Vault settings that determines the behavior for deleting things.
BUT: I alone have multiple times reportet misbehavior or inverted behavior of switches!
It has happen for a switch in the settings.
Then for a switch in the Graph.
Later there was once more a single switch in the Graph.
Not so long ago, there was a switch in the View’s column setting for the date format that suddenly behaved inverse or unpredictable …
– After all these real cases; what do you believe how much I trust the software to be for ever free from bugs like that?
In addition, there was at least two times a bug, that has overwritten the Creation Date with the Last Edit Date, or a completely different date in the year 1970 …
We all have suffered this kind of data loss at least twice.
Not to speak about other kinds of data loss, where whole Objects disappeared or was suddenly empty, or caused a fatal error if the user tries to open them.
(I still have some Objects of this kind!)
AND we still don’t have a truly reliable backup/restore solution …
(This deserves IMHO the most attention!!!)
– At least as long as this is the (very sad) case, there shouldn’t exist a potential dangerous routine in the software that could run amok in case that a new bug suddenly once more ignores or inverts the status of a switch, or a user decision in a dialogue!
That was the concrete case e. g. for the date format switch: It has always worked, but suddenly it behaved inverse and did the opposite thing it should.
I remember that I’ve asked how it’s possible that something like that happen. And Filip answered that such things can happen, because of … (complicated internal logic and so on).
– If we talk about predictable behavior and different users point of view what’s to expect, then it should be clear that definitely really no user would ever expect that a switch (one that always worked) suddenly behaves opposite!
I’m happy that the devs have received the message that many of us are highly suspicious about cascade deleting. And about that the devs promised to built in some safety measures.
But I still fear that if the cascade delete routines exist, they could become triggered by a bug, no matter what the user’s choice was.
Please: first implement a robust backup/restore system before you come up with potential dangerous things like cascade delete!
I’d like to take this opportunity to emphasize once again the importance of an effective and functional undo feature .
And on that point, there’s no debate as polarized:
Those who fear data loss will appreciate being able to undo with a simple CTRL+Z (or CMD+Z on Mac?).
Those accustomed to this type of chain deletion are also used to being able to easily undo their actions (myself included—when I accidentally delete an item, I sometimes hit CTRL+Z to restore it instantly).
Please, can you confirm that this will work properly for all cases of cascading deletions?
)?
.