At the org level, the browse UI treats a site as an ordinary folder. Rename submits:
The destination is the new site root.
There is no confirmation. Submitting the inline rename starts the move. The UI also changes its local name and path before the request succeeds.
The current backend uses a tree copy followed by source deletion. It has no rollback or lock. PR adobe/da-admin#303 causes version and audit history to stay under the old site prefix, while the request can still return 204.
Site rename is a valid legacy DA use case. It needs a separate UI flow from folder rename.
This issue covers legacy DA sites. HLX6 site rename needs a separate migration flow.
Proposed behavior
Keep Rename for a legacy site selected at the org level.
Before sending the request, show a confirmation with:
Suggested text:
Rename {oldSite} to {newSite}?
This moves the site's content, versions, and audit history. Sites with more than 1000 stored objects cannot be renamed here.
Update any EDS project that uses https://content.da.live/{org}/{oldSite}/.
Use Rename site and Cancel actions.
Do not crawl the site in the client. The delete UI's 1000-item guard counts visible files by crawling every folder and every continuation page. The backend rule in #305 counts stored objects, including hidden storage. The backend is the authoritative gate.
Handle the backend response by error code:
site_rename_too_large: show the limit and keep the old site name
site_destination_exists: show that the new site already exists
partial_failure: tell the user that the rename did not complete and a refresh is required
- 204: update the item path, clear the selection, and dispatch
renamecompleted
Do not change the local item name or path before a 204 response.
Hide Cut for a site selected at the org level. Cut and Paste reaches the same site-root move without the rename confirmation. Folder Cut remains unchanged.
This UI change depends on the backend contract in adobe/da-admin#305.
At the org level, the browse UI treats a site as an ordinary folder. Rename submits:
The destination is the new site root.
There is no confirmation. Submitting the inline rename starts the move. The UI also changes its local name and path before the request succeeds.
The current backend uses a tree copy followed by source deletion. It has no rollback or lock. PR adobe/da-admin#303 causes version and audit history to stay under the old site prefix, while the request can still return 204.
Site rename is a valid legacy DA use case. It needs a separate UI flow from folder rename.
This issue covers legacy DA sites. HLX6 site rename needs a separate migration flow.
Proposed behavior
Keep Rename for a legacy site selected at the org level.
Before sending the request, show a confirmation with:
content.da.liveURL that connected EDS projects must updateSuggested text:
Use
Rename siteandCancelactions.Do not crawl the site in the client. The delete UI's 1000-item guard counts visible files by crawling every folder and every continuation page. The backend rule in #305 counts stored objects, including hidden storage. The backend is the authoritative gate.
Handle the backend response by error code:
site_rename_too_large: show the limit and keep the old site namesite_destination_exists: show that the new site already existspartial_failure: tell the user that the rename did not complete and a refresh is requiredrenamecompletedDo not change the local item name or path before a 204 response.
Hide Cut for a site selected at the org level. Cut and Paste reaches the same site-root move without the rename confirmation. Folder Cut remains unchanged.
This UI change depends on the backend contract in adobe/da-admin#305.