You're talking about batch move/copy?
Cannot confirm issue then.

Just select the main item, not the subitems before copy/move!

(Tested with staging version)

I think I may have figured out the OPs issue. It may not be a bug, hard to say. So....

If you batch move JUST the parent item, the children move as well as they are intended and they keep the parent child relationship.

However, if you check the checkboxes for the submenu items too, and then bath move them, they do in fact lose their parent / child relationships.

Exactly. I think in both cases parent/child relationships should be kept. If one wants to copy/move menu items that have children, he/she would probably select them all (parents and children).

For me the current bahaviour is more logical but I'm just another user... ;-)

I agree with @bertmert. The current behavior is the expected behavior. Each menuitem you select to move, will get moved to the specified parent. If you only select one menuitem, the children will be moved as part of the tree, remaining the structure.

Closing as expected behavior.

thats totally illogical. IF only one menu item is chosen AND no parent,
then ok.. your way makes sense.
lets say for example there are 14 children and I want 3, so i select the
13, your telling me that it is NORMAL to have to move 13 others back to
where they should go?
How the heck is this a good UI design?
lets not be lazy as coders and instead be empowering!
Bear
On 9/20/2015 04:11, Thomas Hunziker wrote:

I agree with @bertmert https://github.com/bertmert. The current
behavior is the expected behavior. Each menuitem you select to move,
will get moved to the specified parent. If you only select one
menuitem, the children will be moved as part of the tree, remaining
the structure.

Closing as expected behavior.

—
Reply to this email directly or view it on GitHub
#7909 (comment).

There are valid cases to do it both ways. Without an overly complex wizard to deal with move/copy and breaking an already volatile API in our JTableNested objects (because it's far too easy to break the tree structure of these types of records right now), there is no code change that can be made that is "empowering" without major breakage. Of course, anyone's free to look at the code and try to tackle it if they think they can pull off the type of logic changes needed to make things work in an alternative manner.

Assuming you have
parentMenu
+-- Menu1
+-- Menu2
+--+-- SubMenu2-1
+--+--+-- SubSubMenu2-1-1
+--+-- SubMenu2-2
+--+--+-- SubSubMenu2-2-1

Now you select and move Menu2, SubMenu2-1 and SubSubMenu2-2-1 to Menu1, what should happen with the ones you didn't move? They would end up without a parent since you moved that one away. So that doesn't work. Currently they are moved together with their parent, keeping the tree structure.

I think this way of handling of the menu items and sub-items is outdated. It should be updated much earlier. My proposal is to allow changes in menu structure by simple drag and drop techniques. We have this for menu items ordering now. It would be great if we could change the parents of the menu items by dragging and dropping them here and there throughout the menu structure.

Also, imagine that one could move menu items to the other menu with similar techniques. Nobody would use the "batch" copy/move methods that we have now ever again.

Think about this... How a Joomla newbie could guess that he/she should click the "Batch" button to unhide the options for moving and copying the menu items?

What about an alert or pop up of sorts that shows if you select a parent
AND it's child menu item and click the batch operation? This would work to
educate the newbie user and steer people towards using it the correct way

On Sun, Sep 20, 2015, 3:57 PM hotthemes notifications@github.com wrote:

I think this way of handling of the menu items and sub-items is outdated.
It should be updated much earlier. My proposal is to allow changes in menu
structure by simple drag and drop techniques. We have this for menu items
ordering now. It would be great if we could change the parents of the menu
items by dragging and dropping them here and there throughout the menu
structure.

Also, imagine that one could move menu items to the other menu with
similar techniques. Nobody would use the "batch" copy/move methods that we
have now ever again.

Think about this... How a Joomla newbie could guess that he/she should
click the "Batch" button to unhide the options for moving and copying the
menu items?

—
Reply to this email directly or view it on GitHub
#7909 (comment).

It would be great if we could change the parents of the menu items by dragging and dropping them here and there throughout the menu structure.

PR is welcome.

Actually, I think it's logical that if you check a parent menu item's box, it shouldn't matter if you click it's child menu items boxes or not, they should be moved with it. Otherwise you are destroying the menu structure that the user created.

If the user wants to just move a child item, then they would just check the box for that item only. It's already setup this way anyways. But if you click a parent, it's child items come with it (with association), regardless of if they are clicked or not.

Does what I'm suggesting make sense? Should I ask more people about this on the forum?

For me, it makes perfectly sense as it is now. If I click the subitems, I want to also move them to the selected parent, changing the tree.
It's more flexible the way it is now, and laos the code is less complex. Which is a big win for me.
Maybe the text can be adjusted to indicate that behavior so it's more clear to the user.

I think the case of moving a parent and it's children both to a different (shared) parent is much more rare than someone thinking that they have to select parent and children in order to batch move.

Regardless, we shouldn't ignore the user that just doesn't know. Also, there should be an option to keep the structure. The best case scenario is to at least have this checkbox

so that the user can have the power to keep or destroy their structure.

In terms of making the code more complex, I'm not sure how much really it makes it since we've never committed to that part of the CMS. But, it sounds almost like an if statement to me: if the selection has subitems and that checkbox is checked, keep the subitems parents and include them on batch processing. One could really get cute and make that checkbox show only if it's detected that menu items have been selected that contain subitems

Pr welcome
On 21 Sep 2015 9:06 pm, "Ryan Boog" notifications@github.com wrote:

I think the case of moving a parent and it's children both to a different
(shared) parent is much more rare than someone thinking that they have
to select parent and children in order to batch move.

Regardless, we shouldn't ignore the user that just doesn't know. Also,
there should be an option to keep the structure. The best case scenario is
to at least have this checkbox
[image: screenshot-localhost 2015-09-21 15-00-52]
https://cloud.githubusercontent.com/assets/1244893/10003366/a4029b32-6071-11e5-9a55-c890ffd45ba4.png
so that the user can have the power to keep or destroy their structure.

In terms of making the code more complex, I'm not sure how much really it
makes it since we've never committed to that part of the CMS. But, it
sounds almost like an if statement to me: if the selection has subitems and
that checkbox is checked, keep the subitems parents and include them on
batch processing. One could really get cute and make that checkbox show
only if it's detected that menu items have been selected that contain
subitems

—
Reply to this email directly or view it on GitHub
#7909 (comment).

If you'd welcome that idea, we can take a crack at coding it. Just want to make sure it would be appreciated after being developed

thats 100% how it should be
Bear
On 9/21/2015 08:32, Ryan Boog wrote:

Actually, I think it's logical that if you check a parent menu item's
box, it shouldn't matter if you click it's child menu items boxes or
not, they should be moved with it. Otherwise you are destroying the
menu structure that the user created.

If the user wants to just move a child item, then they would just
check the box for that item only. It's already setup this way anyways.
But if you click a parent, it's child items come with it (with
association), regardless of if they are clicked or not.

Does what I'm suggesting make sense? Should I ask more people about
this on the forum?

—
Reply to this email directly or view it on GitHub
#7909 (comment).

thats even better :D
Bear
On 9/21/2015 15:04, Ryan Boog wrote:

I think the case of moving a parent and it's children both to a
different (shared) parent is /much/ more rare than someone thinking
that they have to select parent and children in order to batch move.

Regardless, we shouldn't ignore the user that just doesn't know. Also,
there should be an option to keep the structure. The best case
scenario is to at least have this checkbox
screenshot-localhost 2015-09-21 15-00-52
https://cloud.githubusercontent.com/assets/1244893/10003366/a4029b32-6071-11e5-9a55-c890ffd45ba4.png
so that the user can have the power to keep or destroy their structure.

In terms of making the code more complex, I'm not sure how much really
it makes it since we've never committed to that part of the CMS. But,
it sounds almost like an if statement to me: if the selection has
subitems and that checkbox is checked, keep the subitems parents and
include them on batch processing. One could really get cute and make
that checkbox show only if it's detected that menu items have been
selected that contain subitems

—
Reply to this email directly or view it on GitHub
#7909 (comment).

don't take this the wrong way Thomas, but as a coder it's really not
important what you think is a win.
What IS important is what the user PERCEIVES as a win.
without the users you'd be out of work :P

Bear
On 9/21/2015 14:17, Thomas Hunziker wrote:

For me, it makes perfectly sense as it is now. If I click the
subitems, I want to also move them to the selected parent, changing
the tree.
It's more flexible the way it is now, and laos the code is less
complex. Which is a big win for me.
Maybe the text can be adjusted to indicate that behavior so it's more
clear to the user.

—
Reply to this email directly or view it on GitHub
#7909 (comment).

don't take this the wrong way Thomas, but as a coder it's really not
important what you think is a win.
What IS important is what the user PERCEIVES as a win.
without the users you'd be out of work :P

It's both. If you do everything the users want, you will loose more in the end.
Code needs to be maintaineable and sometimes you need to educate the user that his idea is stupid

The best case scenario is to at least have this checkbox

I would probably do it just with JavaScript. That will be much simpler. Instead of adding a checkbox, just show a warning which the user has to confirm when he selects children items.

The JS solution gives the user no option right away forcing them to change their original decision. I mean they do technically have an option with some helper text explaining it and a JS fired modal or something letting them know "No, don't do it that way".

The checkbox (just personal opinion) offers a better user experience than a JS fired warning / alert since it allows them to do what they want "on the spot".

Both technically work, The JS solution is most likely less code. Just putting my $0.02 out there. I'm not going to try a PR though until at least everyone can agree on a method