[BUG] In menudropdown we only see one level under the top-level.

[beolafsen]

Oqtane Info

Version - 6.0.1

In menudropdown we only see one level under the top-level.

After deleting the Pages TestLevel2 and TestLevel3 it still occour in the Parent combobox under Add Page.

[thabaum]

@beolafsen Thanks for posting your issue. This issue is due to the design of the theme itself. You may test out other themes available in the marketplace to get this enhanced feature. This will probably not be considered a "bug" but more a feature enhancement request for the Oqtane Cyborg theme.

This was reported by myself a while back in #3280 as you can view this issue for the related responses for working with this issue.

[beolafsen]

@thabaum Thanks for you response. I close it.

[beolafsen]

Hi again!

I still believe that the second part of my error message is to be considered a mistake.

In PageManagement, the pages TestLevel2 and TestLevel3 appear in the combo box "Parent". These are marked as IsDeleted in the database and should not be displayed here.

public IEnumerable<Page> GetPages(int siteId)
{
    using var db = _dbContextFactory.CreateDbContext();
    var permissions = _permissions.GetPermissions(siteId, EntityNames.Page).ToList();
    var pages = db.Page.Where(item => item.SiteId == siteId && item.UserId == null).ToList();
    foreach (var page in pages)
    {
        page.PermissionList = permissions.Where(item => item.EntityId == page.PageId).ToList();
    }
    return GetPagesHierarchy(pages);
}

The stmt
var pages = db.Page.Where(item => item.SiteId == siteId && item.UserId == null).ToList();
should be changed to
var pages = db.Page.Where(item => item.SiteId == siteId && item.UserId == null && !item.IsDeleted).ToList();

[beolafsen]

open Issue again

[zyhfish]

submitted PR #4981 to handle this scenario, we can't change the code in PageRepository as sometimes we need to return the deleted pages such as the recycle bin.

[beolafsen]

Hi! Can perhaps be solved by making two different calls to the repository - one where you get all of them and one where you don't get the ones that are marked as deleted - or submitting a parameter that tells you what you want to have back. Best regards Bjørn-Even Olafsen

[sbwalker]

@beolafsen just to clarify... you are saying that the Page Management (Add/Edit) UI should not include deleted pages in the list of pages displayed in the Parent field. This sounds reasonable however there are some complications to consider due to the hierarchical nature of pages....

For example, if you add a "Child" page under the "Private" page... and then you delete the "Private" page, what would you expect to happen? Currently, the navigation menu will not display the "Private" page - which means the "Child" page will not be displayed either (even though it is not actually deleted) - which seems correct. If you browse directly to the Url of the Child page you can access it - which seems correct as it is not deleted. If you go to Page Management, the "Private" page is not displayed in the list, however the "Child" page is displayed (the display order will appear to be a bit strange because it is missing its parent). And if you choose to Edit the "Child" page the Parent: list currently shows the "Private" page as its parent (even though it is deleted)... which allows the UI to work properly upon Save. However if deleted items were filtered from the Parent: list it would cause problems as the only option it could realistically select is <Site Root> and the hierarchical position of the "Child" page would be lost.

One suggestion which has been raised previously is that if a page is deleted, then all of its descendant pages should also be deleted. This way you can never have active child pages which exist under a deleted parent. The Recycle Bin would also need to prevent users from restoring pages which have a deleted parent (ie. pages would need to be restored top-down). Overall there is a lot of complexity due to the hierarchical structure of pages which would need to be managed by the system.

[beolafsen]

Yes - I see the problem, but I think I would expect that all the childpages also are deleted at the same time. I don't want to have them "hanging" without a parent. Ex: If I delete an Invoice I will expect that all the orderlines also are deleted. Best regards Bjørn-Even Olafsen

[sbwalker]

@beolafsen if all descendant pages were deleted when a parent page was deleted, would you also expect all descendant pages to be undeleted when a parent page was restored from the recycle bin?

[beolafsen]

@sbwalker To be honest, I was not aware of this possibility with Recycle bin, nor do I see that I will use it. All my data is based on sitedata (not module data) - although it can also be because I have both siteid and moduleid in all tables. For me, it will be just as quick to rebuild the pages if I was unlucky enough to delete something I shouldn't have deleted. I can see that this is not the case with the modules that have module data (becase of the moduleId in data), so other considerations must be taken into account.
Now I also see way you have this IsDeleted field in the Page and PageModule table.

Now to your question.
Yes - probably - I think that if I want to restore all the child pages, I would restore the parent page. If I only want to restore some of the child pages under a parent page, I would restore one child page at a time.

Best regads BEO

[beolafsen]

An alternative could also be that when you select a page, everything that belongs to that page and any underlying pages will be displayed and you can choose what to install

[thabaum]

Here is an idea how we can handle this secondary issue:

Enhanced Page Deletion and Restoration Workflow for Oqtane

Deleting Pages

• Move to Recycle Bin:
  • Deleted pages are moved to a "Recycle Bin" under the site root.
  • Parent and child relationships are retained as references for context.

Restoring Pages

• Restore Dialog Box:

  • Allows users to update settings (e.g., title, permissions, parent page) during restoration.

• Parent Page Handling:

  • If parent exists: Default to the original parent during restoration.
  • If parent doesn’t exist: Default to the site root and prompt the user to assign a new parent.

• Child Pages Handling:

  • If a parent page with child pages is restored:
    • Provide an option to restore child pages.
    • Allow users to select which child pages to restore via a checklist.
    • Child pages not selected remain in the Recycle Bin.

Benefits

• Retains context (parent-child relationships) while providing user control.
• Prevents undesired restoration of all child pages by allowing selective recovery.
• Handles site structure changes gracefully, even for complex scenarios.

[beolafsen]

I think this sounds good. Best regards Bjørn-Even Olafsen

[sbwalker]

@thabaum I am not in favor of the "Restore Dialog Box" concept as it does not follow UI separation of concern principles as it scatters page management functionality across the application rather than keeping it contained in one place

Note that the parent/child context for pages is already retained when they are deleted