[4.0] Feature: Adding User(s) Model + View to front-end

[pe7er]

Pull Request to add a new Model + View for Users/User to the front-end.

Note: this PR is an improved version of #24799
It has been decoupled from Articles (the previous version showed (the number) of articles that a User had created).

Summary of Changes

The front-end does not have a model + view to display a list of Users.
You cannot use the back-end model of com_users in the front-end because that model has some authentication so that you cannot get data from the Users table if you are not logged in.

This PR adds a Front-end View + Model for Users and User.
The view can be added to the Front-end by creating a new menu item type "Users > List Users".
The Users View supports Custom Fields.

Testing Instructions

Create some Users that you assign to some User Group (e.g. Author and Editor).

In Menus > Main Menu, create a New Menu Item of type "Users > List Users"

Under the "Users View" tab, configure what the new menu item should display:

• User Groups: select a few
• Select if you want to see the Page Header or not
• Configure if you want to see the Last Visit date of that User
• Configure the Date Format if you want to show it differently
• Configure if you want to see the Online status of that User

Expected result

The Front-end should have a new View that displays a list of Users.
You should be able to navigate the list.

If you select a User, you should see the User page with currently only the name of the user:

The User View supports Custom Fields that have been added to the User.
For the moment you can display all other Fields (besides the Name it already displays) + Custom Fields them by creating a Template Override.

[pe7er]

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

[Bakual]

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?

[pe7er]

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.

[micker]

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

[bembelimen]

JFYI to not repeat all arguments: #21441

[brianteeman]

@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

[Quy]

Use tabs and not spaces to indent in this file.

[Quy]

Suggested change

	COM_USERS_USERS_LASTVISIT="Last Vistited"
	COM_USERS_USERS_LASTVISIT="Last Visited"

[brianteeman]

Suggested change

	COM_USERS_USERS_GROUP_VIEW_DEFAULT_DESC="Displays a list of Users of a Group."
	COM_USERS_USERS_GROUP_VIEW_DEFAULT_DESC="Displays a list of Users from a Group."

[brianteeman]

I cant see anywhere that you can set a global nor can I see a real need for one so just delete this line

[richard67]

@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.

[AndySDH]

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.

[AndySDH]

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

[wilsonge]

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.

[ReLater]

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.

[uglyeoin]

Does this show user articles?

[pe7er]

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.

[pe7er]

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..

[Ruud68]

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.

[uglyeoin]

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.

[AndySDH]

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

[pe7er]

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.

[Ruud68]

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

[brianteeman]

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.

[roland-d]

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

[Quy]

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

[AndySDH]

That sucks. Can somebody else pick it up?

[roland-d]

@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.

[AndySDH]

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

[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.

[Quy]

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

[pe7er]

@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.

[AndySDH]

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

[laoneo]

I would love to see this in the core.

[sandewt]

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.