[DEFECT] Push publishing drops folder Show on Menu and defaultBaseType when the folder already exists on the receiver

Problem Statement

Push publishing a folder that already exists on the receiving server silently discards two of the folder's properties. The receiver keeps its own previous values and the publish job reports success, with nothing logged as an error, so there is no signal that data was dropped.

The receiver-side handler has two branches. The create branch (FolderHandler.java:177) saves the full deserialized folder — either fAPI.save(folder, folder.getInode(), ...) at line 224 or a blanket BeanUtils.copyProperties(localFolder, folder) at line 241 — and is correct. The update branch (FolderHandler.java:257, commented "Folder already exists, lets update its properties with remote folder's ones") instead enumerates properties explicitly at lines 285-292:

temp.setOwner(folder.getOwner());
temp.setModDate(folder.getModDate());
temp.setDefaultFileType(folder.getDefaultFileType());
temp.setName(folder.getName());
temp.setSortOrder(folder.getSortOrder());
temp.setIDate(folder.getIDate());
temp.setFilesMasks(folder.getFilesMasks());
temp.setTitle(folder.getTitle());

Two properties written by FolderFactoryImpl.upsertFolder() are missing from that list:

defaultBaseType is the folder's nullable upload-mode preference added by PR #36649, so a folder's configured upload behaviour is dropped on update alongside its menu visibility.

Line 295 then calls fAPI.save(temp, systemUser, false). Because temp is the receiver's own folder object, FolderFactoryImpl.upsertFolder() reads back and re-persists the receiver's stale values (folder.isShowOnMenu() at FolderFactoryImpl.java:1410, folder.getDefaultBaseType() at line 1424). The values are not merely skipped — they are actively rewritten to what the receiver already had.

The sender side is not at fault. FolderBundler serializes the whole Folder object inside FolderWrapper via XStream, so both values are present in the bundle XML. The loss is entirely receiver-side.

showOnMenu is a regression. Before PR #32341 this branch used a single blanket BeanUtils.copyProperties(temp, folder), which copied every bean property including showOnMenu. That PR replaced the blanket copy with the explicit setter list above and did not carry showOnMenu over. defaultBaseType was introduced later by PR #36649 and was never added to the list.

Impact. Editors cannot change a folder's menu visibility on delivery servers through push publishing at all, in either direction — turning the flag on and turning it off are both dropped. Because folder showOnMenu drives navigation rendering, delivery-side menus stay permanently out of sync with the authoring server, and the only remedy today is editing each delivery server directly. The failure is silent, so the divergence accumulates unnoticed.

Both omissions sit in the same eight-line block; the fix is two lines.

Steps to Reproduce

1. Configure a sender and a receiving (delivery) server with a push publishing environment between them.
2. On the sender, create a folder and push publish it to the receiving server, so the folder now exists on both.
3. On the sender, edit that folder and change the Show on Menu value (either direction).
4. Push publish the folder again. Any filter works, including Only Selected Item.
5. Wait for the publishing queue to report the bundle as successfully published.
6. On the receiving server, inspect the folder's Show on Menu value, or query the delivery database directly:

   select inode, name, show_on_menu, default_base_type from folder where inode = '<folder inode>';
   

Expected: show_on_menu on the receiver matches the value set on the sender.

Actual: show_on_menu on the receiver is unchanged from before the push. The publish job reports success and no error appears in the push publishing logs.

Repeat steps 3-6 with a folder whose defaultBaseType is set to reproduce the second omission. Note that step 2 matters: a folder that has never been pushed takes the create branch and is handled correctly, so the folder must exist on the receiver first. Folders are also auto-created on a receiver as a side effect of pushing assets inside them, which is enough to put a folder on the broken branch.

Acceptance Criteria

• Changing a folder's Show on Menu value and push publishing it to a server where the folder already exists updates show_on_menu on the receiver to match the sender.
• This holds in both directions — enabling and disabling the flag.
• The folder's defaultBaseType (default_base_type) is likewise copied to the receiver on update.
• A first push of a folder that does not yet exist on the receiver still carries both values correctly (no regression to the create branch at FolderHandler.java:177).
• A regression test covers the update branch, asserting that every column in FolderFactoryImpl.UPSERT_EXTRA_COLUMNS is copied by FolderHandler's update path, so that adding a future folder column cannot silently reintroduce this class of bug.

dotCMS Version

Reported on 26.07.13-01 (Current Release / dotEvergreen).

• showOnMenu: affects every release containing PR #32341 — first release tag carrying it is v25.08.04-01 (2025-08-04), confirmed via git tag --contains 4911172778. Still present on main. Tag v25.01.09-01 also contains the commit, so the 25.01 LTS line should be checked for backport.
• defaultBaseType: affects releases carrying PR #36649 (merged 2026-07-28) onward. The reporting version predates that column, so the reported symptom is showOnMenu only; the defaultBaseType omission was found by code review against main and has not been observed in the field yet.

Severity

High - Major functionality broken

Links

• Freshdesk ticket #39224
• Regression introduced by #32341
• defaultBaseType added by #36649 (task #35577)