Thanks for your corrections @brianteeman
I've fixed it with commit ac4d027

I think the reason why this views are missing is security related.
I don't see a reason to make a list of users available on my sites frontend, that just screams for potential security issues ?
@joomla/security should have a look at this for sure.

What is your use case?

I understand your concerns. We have to double, triple, check that the views can only be used if they are made available on purpose, via a Menu Item.

So you won't just make a list of users available on you sites front-end:

• the Lists will only show if a Menu Item has been created.
• the Menu Item of a list of Users can be set to Registered

Use cases

• Magazine websites - Categories + Articles are already in Joomla. Display a list of all Authors (Users that are in the "Author" User Group) is not possible without using a 3rd party extensions. It would be great if we could display a list of selected users with just the Joomla core. We would like to have that functionality for https://magazine.joomla.org/
• Association + Portal websites - Can display a list of their Members (including Custom Fields like Photo, membership, social media links, etc) to their own Members using a Menu Item of type Registered
• Other case - With a template override you could hide any Personal Data that is now available in the Users table, and only show the Custom Fields that the Users can add themselves. In that case this new front-end User Model is only used to navigate between those Custom Fields.

for me allow user admin in front is realy great addition !!!
mabe category creation can be perfect too

JFYI to not repeat all arguments: #21441

@pe7er and I discussed that PR during jday nl and this is very different. It is not hardcoded to be connected to com_contacts. It doesn't duplicate existing functionality and it actually works and is testable

Re the links to users pages

1. Can there be an option for it to be a link or just plain text
2. The users page link is not exactly sef
   example
   http://localhost/joomla-cms/index.php/userlist?view=user&id=532
   I expected more like
   http://localhost/joomla-cms/index.php/userlist/nigel

I have tested this item ✅ successfully on 7103b3b

1. Can there be an option for it to be a link or just plain text

Sorry, what do you mean?

2. The users page link is not exactly sef
   I expected more like
   http://localhost/joomla-cms/index.php/userlist/nigel

Yeah, I understand your point.
However, to create such nice URLs (the last part), Joomla uses unique alias fields.
The alias field.is not available in the User Manager.

So when your site has two Nigels, all links to people with the same name (Nigel) will go to the 1st Nigel in the database :-)

I have tested this item ✅ successfully on 7103b3b

Great feature. I always wondered why there wasn't a list of users views on the frontend.

I have tested this item ✅ successfully on 7103b3b

Great feature. I always wondered why there wasn't a list of users views on the frontend.

@wilsonge Is there anything speaking against this PR beside the conflicts? E.g. any PLT decision not to want that? If not, then @pe7er could solve the conflicts, if necessary we test again and then it could go RTC.

Well right now it seems that this PR lacks the basic template functionallity that displays the user information. Profile fields and User custom fields. It's a bit barebones right now if clicking on an user shows nothing but just its name.

So when your site has two Nigels, all links to people with the same name (Nigel) will go to the 1st Nigel in the database :-)

Not true, you can use the username, the username is unique

This hasn't been discussed either way as far as I know. It's something that came up in my London User Group like this but with custom fields etc.

Tbh I wouldn't prioritise this right now. It's not something we are going to have in 4.0 at this stage as we're focussed on the beta blockers. Until a 4.1 branch is set up where this would probably be a viable feature there's not a huge amount of point in focussing on this.

I have some GDPR concerns when a registered user can't block the display of its data in front-end. Whatever it is.
But I'm no jurist.

Does this show user articles?

I have some GDPR concerns when a registered user can't block the display of its data in front-end.

Why? The user data is already available in the website and visible in the back-end.
As long as you are transparent about the usernames becoming visible for other users (e.g. in privacy statement and a message on the registration form), I don't see issues with that.

Does this show user articles?

No, my previous PR did have that option: #24799
This PR is more generic and makes it possible to create a template override that displays the users articles..

What is missing is a unique user alias (#__users change, router change, method to create unique alias based on username / name / ???) that needs to be added to the user table. the alias is needed for creating unique url's. Without this, this will technical work but not from a user / seo perspective.

Does this show user articles?

No, my previous PR did have that option: #24799
This PR is more generic and makes it possible to create a template override that displays the users articles..

Maybe not for right now but that's the main thing I see missing from Joomla! if you want to create a blog. That's the main purpose I see for this pull request. And decoupling com_contact makes it more user friendly.

Again, offering a PR that displays an empty profile unless people create a template override is not useful. At that point users would not creating a template override, they would create the template period. There needs to be some data displayed by default in the default template.

Also again, this regarding the SEO usernames:

you can use the username, the username is unique

Again, offering a PR that displays an empty profile unless people create a template override is not useful.

I do not agree with that. The purpose of this PR is to make the User Model available in the front-end. Currently you can only display a list of users or display a single user using a non-core component.

When this PR is added to the Joomla core, the User Model can be used in the front-end and then other functionality can be added on top of that (e.g. a list of articles written by that user). First with using a template override. Or we can extend the functionality with a new PR later.

Also again, this regarding the SEO usernames:

you can use the username, the username is unique

until a user put's in an email address as username: get ready for the trolls :) so there should definitely be some conversions.

Also all com_users back-end views should be adjusted to make the alias possible / editable

For the username to be used as an alias it would need to be sanitised by using the same functionality we already have for this.

@pe7er Any interest in fixing the conflicts and picking this up or should the PR be closed?

@roland-d The branch is deleted so I assume he is no longer interested.

That sucks. Can somebody else pick it up?

@Quy Thanks for that, I missed the deleted branch. In that case I will close this pull request and if someone else is interested they can pick this up in a new pull request.

Nobody will ever see or notice this again if the pull request gets closed. @roland-d

@AndySDH We cannot keep PR's open forever. This PR being buried at page 1234 is not noticeable either. If we ever get to the point where we have a plan of what should be in which release, we could make a "job board" with features for people to work on.

@AndySDH There are two open issues #26973 & #28294 referencing this PR.

@roland-d @Quy @AndySDH I had git-out-of-sync issues with my local installation + my Joomla-CMS fork.
As I had submitted my code already as PR to Joomla-cms, I removed my Joomla-cms fork on github and reforked.

I have not updated my PR because of all the discussions in this PR I have a feeling it is not wanted.
And it would probably not be added in 4.0 #25030 (comment)

If there's demand for my feature and there is more possibility that it will get merged, then I am willing to redo it.
But I don't want to spend time into something that won't be merged anyway.

Well if it won't be merged in 4.0, it would definitely come in 4.1, it's a great feature for sure!

I would love to see this in the core.

But I don't want to spend time into something that won't be merged anyway.

Too bad about the energy, you are already a long way towards realization.