Pasting when there was nothing copied creates an action named "Set category/group <null>".

Also, the fact that the paste action in the popup uses "category" or "group" in the name is odd since "Paste Group Values" will actually paste a category if that's what you have copied. It should just be "Paste Copied Values" instead.

Pasting when there was nothing copied creates an action named "Set category/group ".

Also, the fact that the paste action in the popup uses "category" or "group" in the name is odd since "Paste Group Values" will actually paste a category if that's what you have copied. It should just be "Paste Copied Values" instead.

I think copying properties from a category and pasting them into a group within that category should only paste the group's properties. This allows you to paste multiple groups within a single category without having to copy each group individually.

But if the properties of a category are pasted into a group that is in another category, nothing should happen.

Feature seems to be working well. Those commits need to be squashed, however.

I found unexpected behavior when pasting on multiple nodes.

I found unexpected behavior when pasting on multiple nodes.
Screen.Recording.2025-10-13.130423.mp4

Could this come from the way I'm doing the undo/redo ?

The undo/redo usage looks correct, but for some reason it creates "Set category" as global action and makes individual action for each property. Something is wrong.

Yeah, the thing is, this code

LocalVector<String> properties;
const String action_name = vformat(TTR("Set group %s on node %s"), group_name, object->get("name"));

_collect_properties(properties);

EditorUndoRedoManager *undo_redo = EditorUndoRedoManager::get_singleton();
undo_redo->create_action(action_name);

for (const String &property_name : properties) {
	undo_redo->add_do_property(object, property_name, clipboard[property_name]);
	undo_redo->add_undo_property(object, property_name, object->get(property_name));
}

undo_redo->commit_action();

Is only called for the object that is selected in the inspector (so the last one selected?). So the values pasted onto the other object are handled by something else.

Ok I see what's the problem, but fixing it will involve modifying MultiNodeEdit.
MultiNodeEdit has undo/redo built-in in its _set() method. If you call add_do_property() on it, the undo action will cause another undo action. MultiNodeEdit itself is not recognized as part of the scene, hence there is history mismatch on to of that.

This is a bit messy, so I think you can just put a big FIXME comment and I will do a follow-up PR once this is merged.

EDIT:
Actually I came up with how to implement it independently. I will open a fix later today.

Could you squash your commits? See our pull request guidelines for more information

Done

Thanks!

Does not seem to work on ShaderMaterial