Issues while trashing a page and creating a new page with the same slug

**Current behaviour** - Today in CMS if we try to trash the pages, there are a few ways to do it.

- Using the “Move to trash” option in the page menu
- Setting value of “trash” dropdown “true” in the page settings
I.e, (Page Menu -> Page Settings -> Info -> trash)

**Method 1**: If we use the “Move to trash” option the ‘slug’ and the ‘path’ for the page are **de-duplicated** and the trash field is set to **true**. These changes are currently applied only to the draft document of this page in MongoDB.

**Method 2**: Only the trash field is set to **true** in the draft document of this page. The slug and the path fields of this document remain unchanged.

_In both the methods the value of the trash field is propagated to the live document of the page, only after committing page explicitly (i.e. as a separate user-initiated action)._

**Problem Statement**
_Method 1_

- The live slug, path, and trash fields in the live document are not updated until a publisher commits the changes explicitly. This results in the following user scenario,

1. A user trashes a page (let’s call this **page 1**) in the draft mode

2. While this is waiting to be committed to the live mode by a user with the appropriate permissions, another user can create a new page (**page 2**) with the same slug since page 1 has been de-duplicated in the draft mode.

3. When the other user tries to get **page 2** published to the live mode, the live document of **page 1** is still using the slug, resulting in a conflict, which causes Apostrophe to suffix **page 2’s** slug with a number, defeating the purpose of the de-duplication process.

- When a user explicitly commits a trashed page, the slug field gets de-duplicated in the live mode, while the **path** field doesn’t get de-duplicated. We’re not clear why this discrepancy is present and if it’s intentional.

_Method 2_

1. In method 2, since the slug and path fields are not changed by the “de-duplication process”, the user has to **manually change the slug** of the previously trashed page to be able to create a new page with the same slug.
2. If we delete the page by using method 2, the user is immediately redirected to the **404 page**. Instead, the user should be redirected to the parent page just as it happens in Method 1.

**Proposals for fixing these issues**
_Solutions for problems of Method 1_

1. We can propagate all the changes from the draft mode to the live mode of the page as soon as
2. it is deleted, instead of doing that after publisher commits the page. Thus preventing the suffixing (random number added to the slug to maintain uniqueness) of the slug of the document.
3. Or we can tweak the “_slug-taken_” API to also check the live mode of the document if there exists a draft document with trash field set to true and give an intuitive error message like “_Please commit the changes before creating a new page with the same slug_”. Thus preventing users from creating a new page with the same slug, before the old page is deleted and committed properly.

_Solutions for problems of Method 2_

1. Method 2 should also follow the same process as method 1 (i.e., the de-duplication of the necessary fields should happen) in cases where the “trash” field is updated.
2. The update method usually redirects the user to the same page at the end of an update operation, but in this case, since the page is deleted it will result in a 404 page. We have to handle this specific scenario by setting the “_URL_” property as that of its parent page at the end of the update operation.
3. Or we can remove the option to trash the pages inside the page settings altogether since we already have an option to delete the page through “Move to trash” option. And multiple ways to achieve the same thing will only add unnecessary confusion to the users. Instead, we can only give an option to rescue the pages that have already been trashed/deleted inside page settings.

Begin by reproducing both trash flows, then trace the page settings update, Move to trash action, and _slug-taken_ API across draft and live documents. Done means the chosen behavior consistently handles slug and path de-duplication, prevents publishing conflicts, and redirects users appropriately after trashing a page.

Written by the indexing model from the issue text.