(updated title to show it is for 4.0)

If this is ready for testing, please give a hint.

I am confused by the objectives of this new access column

• what is the problem that is being solved
• what can I do now I couldn't do before
• what happens with existing users. the column is blank for them
• our access and viewlevels are confusing enough atm and I "think" this makes it worse - for example I can create a new user in the admin and select the access as super users. But that is not the same as changing their group to Super users

contact form

Isn't this duplicating the functionality already possible with the user - contact creator plugin?

New menu items

I couldnt test this as the two options were not present in the list of available menu types that can be created

The goal of this project was to provide front end menu list items for users and a detail page. This solves tow issues:

• The long outstanding problem that the user menu item is not working on the front end
• That we can decouple com_contact as you need com_contact to show a list of users on the front end.

The access flag is a security measure that the admin can define who can see the user on the front end. I was the driver behind that flag and not to have just a yes no button if the user details should be available on the front or not.

The access flag is a security measure that the admin can define who can see the user on the front end.

Per-user setting should be set by the user in user profile. Admin could set the global setting in com_users to allow/disallow frontend profile viewing. Need to think about this from user perspective too.

The goal of this project was to provide front end menu list items for users and a detail page.

Why? There are many extensions for that. Is it really something that the majority of websites would want? If not then it doesnt belong in the core

That we can decouple com_contact as you need com_contact to show a list of users on the front end.

If you need a list at all - see above.. And as I stated this is duplicating functionality available with the contact creator plugin which allows much more advanced use.

The access flag is a security measure that the admin can define who can see the user on the front end. I was the driver behind that flag and not to have just a yes no button if the user details should be available on the front or not.

That is completely unclear from the UI. I read it as what is the access of this user. Again completely unnecessary to add to all users when the contacts can be used for this

Sorry but this makes no sense to me at all for a core contribution. It's not about the code but about should it be in the core

Is it really something that the majority of websites would want?

Nobody can answer that, not even you.

And as I stated this is duplicating functionality available with the contact creator plugin

The creator plugin creates a contact when a user is created and has nothing to do with the contact form. Means we have even more bloat, as you have then a contact per user.
I was talking with several people before GsoC started about that project and the contact form is a feature some do need. So the student duplicated that functionality. But this is only till the decoupling is finished.

As I said the overall goal is to be able to decouple com_contact. With custom fields in combination with the user component, this is possible now. Most maintainers do agree that we should slim down the core so this is a step into that direction. If you want to have a contact extension then take one from JED and not the opposite.

Is it really something that the majority of websites would want?

Nobody can answer that, not even you.

So go to the joomla showcase site and show me how many sites have a user list and then compare that to how many have a contact list

This is not slimming down the core it is bloating it. Sorry not wasting my words on this any more. It is a useless feature that doesnt belong in core.

Tend to agree here. Having a core frontend user profile view IMO is a nice to have capability, but I don't think it needs to come with all the extra stuff being proposed here, especially the bits related to access that just adds even more confusing things to an already confusing management interface.

I am sorry but I also don't see this as a needed addition to the core package

PD (PLT) accepted these projects so I don't see a reason why we are discussing again if this should get into core or not. What we can discus here if the code is correct and all the features are implemented the right way.

@mbabker we went with access levels basically because of security reasons. Like that an admin or the user has then to actively activate a user for front end listing.

Sorry but just because a project was chosen shouldn't mean we have to merge the resultant code. That's never been the case before. Surely as a developer you understand that what might appear to be a good idea on paper isn't necessarily a good idea on practice.

@brianteeman that Decision should be made before chose Project.

Gsoc is about introducing students to open source.

This is only part of GsoC. It should also help the open source projects. If we would do something which will not get accepted in core, then there is no reason to ever start that project. It is a big amount of time the student and the mentors do put into that project. And when it gets trashed at the end then it leads to big frustrations. The GsoC admins learned from the past and did put the proposals into Production for voting, that we can add something valuable to the core and not just waste time and energy.

This
unlike other already merge features

1. does not break anything (or at least any breaks / bugs should be easy to fix)
2. does little to complicate common website tasks / UI
3. does little to hurt or compete with 3rd party (i mean 'social' extensions) even if one would create a layout overrides to add more stuff to it, still it will not compete with them ... much
4. will be easy to maintain

Not accepting also considering the above points, is a bad message as @laneo said

I understand the only argument against this (which i admit is a good argument) is that it will be uncommonly useful
if so the project should not have started at all

I mean the reason for rejecting this was "known" before the project started,
unlike reasons 1, 2, 4 that may have risen after the project completed

A view named users with a list of users in a user group taking into consideration access levels when displaying

I do not see any menu type for this so cannot test

A view named user that displays the details of a chosen user, including a contact form similar to the one from contact component.

The form is not available until you go into com-users options and save

The view will not display until you go into com_users user and save every user so that the access field is created. Otherwise you have access denied

The form has no language strings

Applying PR got:

he GsoC admins learned from the past and did put the proposals into Production for voting, that we can add something valuable to the core and not just waste time and energy.

Just because the project proposal was accepted (which at the time was nothing more than a couple paragraph abstract at best) does NOT mean that the resultant code MUST be accepted. The end result should be evaluated the same as every pull request and not forced through simply because it has the GSoC label on it.

And if you could please evaluate the comments about the code and make it work so it can be tested then it would obviously help your case to get this accepted. Right now as I have written twice before there is NO code to display the user list

Sorry but I am closing this. There has been no response to requests to at least get it into a testable state

The student promised to have a look. Perhaps she needs some more time.

It can always be re-opened if that ever happens