While this edit does mean that the custom position IS displayed when you edit a module in a custom position the custom position is still NOT displayed when editing another module. This means that while you can move a module from a custom position to a position defined in the templatedetails.xml you cannot do the reverse.

Yes that is correct.

I don't think on frontend module position dropdown should have all custom positions. I don't know whether this is the requirement or not. I remember you saying that module position should behave on frontend as it does on backend. I don't agree with this.

This edit will allow users to edit module (positioned on custom position) on frontend. Currently they can't do it without changing its position to a position defined in the templatedetails.xml

Hard to explain to a user that they can move a module from one position to
another but not to all module positions

See no reason for the frontend to work differently from the backend, what is the justification for that?

It should behave the same, yes. If it's possible of course.
I don't see a reason why it should not.

@sovainfo
Assuming user doesn't have permission or can't change frontend template from frontend, Let there are two templates TemplA & TemplB having custom-posA and custom-posB as custom position respectively.

Now backend will show both positions (if Active) under position dropdown. And if the same behaviour is provided on frontend too then user can choose either of two positions through dropdown.

If TemplA is active and user chooses custom-posB as a position of a module then he/she won't be able to edit the module again as it will not be visible anywhere on the current/active template anymore.

I know there are lots of ifs, I think it is a valid and possible scenario in which something unexpected will and probably can happen leaving the state un-editable for the user having restricted rights.

@Bakual I think it is possible. It is just that whether we want it that way or not.

There is no protection against stupidity! Not everything can be done from front-end, possible mistakes have to be corrected in the backend. Considering these misstakes can be made with the reduced options, you might as well allow them to be made with the custom options as well.

When the experience in the front-end is going to be different from the back-end don't bother to allow it in the front-end!

So in conclusion we should not give option to select any custom position on front-end, Am I right?

The conclusion is that you can't prevent users from doing stupid things anyway. Like for example unpublish the module which can't be fixed from frontend anymore. If you try, you restrict users who want to do perfectly fine things, which is worse.

As said, the frontend should behave exactly the same as the backend. There is no reason to restrict the frontend editing in functionality.
So please allow the users to select any custom position (or even create new ones) exactly as it is in backend.

In my opinion you should be able to select the custom positions in the front-end. Those are the positions used on the site.

I have added another commit which basically adds all active positions in the list. Same as back-end behaviour, user now can select any custom position currently active and can assign new custom position.

Note: There is lots of duplicated code (copied from com_module). I didn't wanted to make dependency of front-end module editing on back-end com_module.

@Achal-Aggarwal can you write a Test scenario, so people can test your patch?

I have tested this item ✅ successfully on cda9f80

Added test instructions to the original post

-->I have tested successfully
Before Patch

After Patch

I have tested this item ✅ successfully on cda9f80

RTC. If a maintainer merge this before the CS Pr gets merged please ping me CS PR against this repo is: Achal-Aggarwal#1

@Achal-Aggarwal can you merge the CS fix so we can merge this one. Thanks

@rdeutz feel free to merge i can send a PR after the merge this PR is over a year old.

done at #11843