Looks good on quick look. Redo of j3 version?

Noticed you do not skip "mirror" element of dragula.js. You think it will not cause the same issue as was fixed before? in #33909
Btw, if do final calculation at "dragend" event then the "mirror" element will be already removed.

Looks good on quick look. Redo of j3 version?

Should work in the same way with J3 except that in J3, we submitted data of all records. This version, a bit improvement because we only submit data of the record needs to be updated only

Noticed you do not skip "mirror" element of dragula.js. You think it will not cause the same issue as was fixed before

Could not say that I understand how dragula works. But base on my debug, that mirror element is always the latest row when we do querySelectorAll, so it is OK me (tried some console.log to check the submit data, tested and it works well in my test)

Noticed you do not skip "mirror" element of dragula.js. You think it will not cause the same issue as was fixed before?

Probably not as the rows are container children and the mirror element is before the body end...

const rows = [].slice.call(container.querySelectorAll(orderSelector));

I have tested this item ✅ successfully on 6b4d90e

Categories are fine, articles not but there's an issue for this view: #33936

I have tested this item ✅ successfully on e61426b

Maybe one of these days the JSST @joomla/security team might actually acknowledge and reply to my email about a security issue related to this... 12 days and not even an acknowledgement or initial response.

edit: not "related" to the changes in this PR, but "generally related to reordering", sorry.

but "generally related to reordering", sorry.

Is it J4 specific? (or in plain English did I messed up big time?)

nothing to do with your work :) its in PHP :) - I've pinged them again today and @richard67 directly to see if I can get responses... its like a ghost town trying to contact the JSST

its in PHP :)

I think I spotted it, it's a 1 line fix if I got it right?

yes probably - but probably effects Joomla 3 also

yes probably - but probably effects Joomla 3 also

Confirmed

@PhilETaylor @dgrammatiko If I understand that issue right, maybe it is not really a security because we at least check edit state permission during saving ordering process already

And maybe we should do the fix for J4 only. If we do that fix in J3, it might make third party extensions broken for that task (because there could be extensions do not pass that data in save ajax ordering request in URL)

Just blind guess :D.

This is why we have a whole team dedicated, that should be addressing this themselves. Instead all of my emails have been ignored.

The current state of that team is undeterminable.

If my emails about this minor issue are ignored, what is to say that major issues reported by others are also being ignored by the projects JSST team

The ACL check, is no substitution for correct request Security.

And yes this should be fixed in 3, as well! Not fixing security issues because they might affect 3PD is simply unacceptable, And this project has always made the right decision previously to implement request Security correctly

And because of the nature of the security fix required, it has to be handled by the JSST team, who can then merge it by release lead just before releasing the next version of Joomla! 3

Finally got a reply from the team, they have confirmed the issue, and they are working on a fix for joomla 3.

Sorry to hijack this PR comment thread

Good to know that. And I was also wrong when assumed that the fix is backward incompatible. Actually, J3 is working in different way with J4 (the whole form data is serialized and submitted, so the fix is safe for J3, too)

I have tested this item ✅ successfully on e61426b

RTC

Thanks! Good work!