Please add "[4.0] " at start of Title.

Sorry mate. Forgot to add that. Was too focused on explaining the issue. Cheers.

@wilsonge can you please comment?

Cannot confirm Issue. But the move of the Subcategorie is only shown after Refresh like cklicking on "Categories" at Sidemenu.

All: can confirm that AFTER a parent Category move, and a CTL F5 screen refresh, the child Category has, in fact, been moved with the parent. This seems to be clumsy and a "mystery" action that a user must take to make the list appear properly. Wonder how everyday john-doe user would know that? Do you think that, after moving a Category, that a "forced" screen refresh might be a solution?

This isn't expected Behaviour.

What isn't expected behaviour? The user does not expect the list to display with the sub-categories? We do not understand what you are saying.
It should be a reasonable expectation by a user that when a Category with Sub-Categories is moved, that it should display that without having pre-informed knowledge to refresh the screen. My questions is: how would they know to refresh the screen? In other instances, changing the Status of an item, the screen refreshes and the success message appears.
But this does not happen when moving a content item.
How about a popup that says: Refresh this screen??????

Its not expected to have to refresh the Screen. It should be as always in other Parts.

We agree then, that moving a Category with Sub-Categories, should not require a manual execution of a screen refresh by the administrator. However, it they do not, the list does not display properly unless they leave the view and come back to it, same-same as a screen refresh. Therein lies the issue. The screen does not refresh on its own, which is should - just like a Status change action executed in the list view using the icon.

sure, its written in #24430 (comment)

I give up. I'm rowing up the wrong river trying to explain a problem.

maybe a language problem but i confirm you all the Time :-) The Difference is i gave Info to Dev. that after a Refresh it looks fine.

Yes, AFTER a refresh it does look correct. But, if you were an administrator, and did not know that a screen refresh was required, what would you do if the list view did not change. You would assume you did something wrong.

Why, after a Category is moved and dropped into place, cannot the screen refresh itself.

It does that when changing the Status of an item in the list view.

It is a bug and it needs to be fixed - we all agree

On Mon, 1 Apr 2019 at 17:49, 200MPHMEDIA notifications@github.com wrote:

Yes, AFTER a refresh it does look correct. But, if you were an
administrator, and did not know that a screen refresh was required, what
would you do if the list view did not change. You would assume you did
something wrong.

Why, after a Category is moved and dropped into place, cannot the screen
refresh itself.

It does that when changing the Status of an item in the list view.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#24430 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8fcG6BABHsb-woNI7WVIR8cyeq5dks5vcjitgaJpZM4cUdDV
.

--
Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
https://brian.teeman.net/ http://brian.teeman.net/

Thank you so much Brian!!! At least someone recognizes it as an issue and suggests it be fixed, which is what I said in the beginning. Cheers for that!

Its not expected to have to refresh the Screen. It should be as always in other Parts.

@franz-wohlkoenig can you please mention anywhere that it already works as expected?
I just tried to find an example of the expected behaviour and took a look at menus, same problem exists there too.
just to check if i understood it correctly, "it is expected that when dragging a parent category, all the subcategories move with it." what if a parent has more than 50 children and one tries to drag it to the top of the list?

Closing this due to not receiving required information to determine if this is a bug or not. If you feel this still needs review, please open a new tracker entry with as much information as possible to ensure it can be reviewed properly

Re-opened -

I can't replicate this. I've tried the test data, moved the template category (has subcat atomic,beez5 and beez 20) out of the parent category (joomla) and back in and in both cases the subcategories were moved as expected

We have another similar issue to this (I think its about deletion) wherever there is nested data. Its due to the order that parents and children are processed.

Ok, it might be but I was going through the js backlog in the projects so I tested this one

If I remember correctly this is NOT about moving the category but using the drag and drop to change the order. There definitely was a problem in the past that the entire tree would not move but that has been fixed some time ago.

I recommend closing this as resolved elsewhere - it can always be reopened if I am wrong (but that never happens?)