Page as a widget - issue with subpages (hierarchical view)

Bug Reports
, ,
1

What’s The Bug?

If you have created a widget from a page and create new (sub)pages within this page, these subpages are inserted into the hierarchy below the main page as expected.

  1. However, if a subpage is deleted inside or outside the widget, it remains in the widget even though it is already in the recycle bin. On the main page, the page link is then grayed out and marked as ‘deleted’. So apparently this is the intended behavior (although one would actually expect deleted pages to disappear from the widget as well).

  2. If one of the subpages of the widget is duplicated inside the widget or on the main page, then this copied page is not inserted into the hierarchy. It would be expected that every change is synchronized on the main page and the widget.

  3. In addition, a page duplicated within the widget or on the main page is not an independent copy at all, but a synchronized copy that dynamically reflects every change to the original file. A synchronized copy of a subpage makes no sense in this context. This might be the reason for issue 2).

How To Reproduce It

  1. Create a page, make a widget of that page
  2. Create subpages by clicking the + in the widget
  3. Create new subpages on the page itself
  4. Delete subpages inside and outside the widget
  5. Duplicate subpages, rename one of the duplicates, see what happens

Image or Video

duplicate_subpages.png
duplicate_subpages.png786×589 54.6 KB

The Expected Behavior

  • One would expect a synchronization in the display of subpages on the widget and on the page.
  • The fact that deleted pages are still displayed in the widget is probably intentional, but the meaning is not recognizable.
  • Duplicated pages are not expected to be synchronized pages, but that independent copies are created by duplication.

Device

iMac

OS

macOS Sequoia 15.3.2

Anytype Version

0.45.10-beta

Network Mode

AnySync

Technical Information

OS-Version: darwin x64 15.3.2
App-Version: 0.45.10-beta
Versionsnummer: build on 2025-03-12 15:48:51 +0000 UTC at #4987f5f7fd0c514426cbdca6626299d2989b1d21
Bibliotheksversion: v0.40.0-rc7
Anytype-Identität: A6nu7vz891FKvFggksu3HdNpVmvcKrURYW3236JYBzSxZ5w5
Analytics-ID: db6eb2b8-aecb-4e0e-aa76-e4bcdcbdae6e
Geräte-ID: 12D3KooWEtm7fJXkeHGQ18GrVVmHqwYyueL8nNjjA1QnckR1DSQA

2

This is a normal behaviour since link block remains on the page even if it’s archived, it’s not removed because it can affect page structure dramatically (i.e. be the last block inside a column resulting in removed columns).

What can be done here is show archived objects in widgets with slight design changes.

3

Ok, that’s an argument, I understand your point of view, but as a ‘simple’ user I can’t understand it.
And concerning ‘synchronized’ subpage duplicates - they can’t be intentional, can they?

4

I would say this is not intentional but raises some technical questions. Since you can select as many blocks as you want (ie 100, 500, 1000) there can be any amount of objects, so clicking one duplicate button will create as many duplicates as you have link blocks in the selection. So while we do not offer an undo action for this which will revoke object duplication it may lead to unintended results.

We are currently in the process of discussion of this implementation.

7

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