?
Referenced as Duplicate of: # 15244
avatar coolcat-creations
coolcat-creations
6 Mar 2017

image

Maybe i´m missing something but there is no after Display, before Display and After Title in User?
Can this field be removed in User-Context?

Also if i set this option to no, the field is still displayed.

avatar coolcat-creations coolcat-creations - open - 6 Mar 2017
avatar joomla-cms-bot joomla-cms-bot - change - 6 Mar 2017
Labels Added: ?
avatar joomla-cms-bot joomla-cms-bot - labeled - 6 Mar 2017
avatar coolcat-creations coolcat-creations - edited - 6 Mar 2017
avatar coolcat-creations coolcat-creations - edited - 6 Mar 2017
avatar laoneo
laoneo - comment - 7 Mar 2017

Difficult to solve.

avatar coolcat-creations
coolcat-creations - comment - 7 Mar 2017

Idea from a nondev :) can the showon parameter help?

avatar joomla-cms-bot joomla-cms-bot - change - 7 Mar 2017
Title
[com_fields] Automatic Display in User Context makes no sense?
[com_fields] Automatic Display in User Context doesn´t apply in this context
avatar joomla-cms-bot joomla-cms-bot - edited - 7 Mar 2017
avatar laoneo
laoneo - comment - 7 Mar 2017

Not really, we need to do some kind of callback to the extension if it supports the automatic display events. Another thing the extension dev needs to take care of when she wants to integrate com_fields into their extension.

avatar franz-wohlkoenig franz-wohlkoenig - change - 30 Mar 2017
Category com_fields com_users
avatar joomla-cms-bot joomla-cms-bot - change - 30 Mar 2017
Title
[com_fields] Automatic Display in User Context doesn´t apply in this context
[com_fields] Automatic Display in User Context makes no sense?
avatar joomla-cms-bot joomla-cms-bot - edited - 30 Mar 2017
avatar joomla-cms-bot joomla-cms-bot - change - 30 Mar 2017
The description was changed
avatar joomla-cms-bot joomla-cms-bot - edited - 30 Mar 2017
avatar franz-wohlkoenig franz-wohlkoenig - change - 4 Apr 2017
Category com_fields com_users com_fields com_users UI/UX
avatar franz-wohlkoenig franz-wohlkoenig - change - 4 Apr 2017
Status New Confirmed
avatar joomla-cms-bot joomla-cms-bot - change - 4 Apr 2017
The description was changed
avatar joomla-cms-bot joomla-cms-bot - edited - 4 Apr 2017
avatar AlexRed
AlexRed - comment - 13 Apr 2017

Same problem also for Contact Field.
For me we need at least write in the tooltip that it is only for article and not for Users and Contact.

avatar mbabker
mbabker - comment - 13 Apr 2017

The tooltip shouldn't say that. To "really" fix this the field would have to be aware of the supported plugin events for a context. It is not restricted/available to articles only, it just so happens if the core components only articles supports all of the listed contexts.

avatar AlexRed
AlexRed - comment - 13 Apr 2017

Fantastic, can your fix hide the "Automatic Display" parameter only in user and contact field ?

avatar mbabker
mbabker - comment - 13 Apr 2017

It's basically what @laoneo last comment says. When generating that field, it would have to be smart enough to call into the "owning" extension for a context to figure out what events it displays and build the list that way versus the current hardcoded list that exists now. So programmatically once the callback thing is sorted out it's an easy fix, problem is getting to that point isn't easy.

avatar AlexRed
AlexRed - comment - 13 Apr 2017

And in this mode I hope we can set different default "permission" for a context.
Allowed "Edit Custom Field Value" for User and Contact Mail fields :)

avatar laoneo
laoneo - comment - 13 Apr 2017

You can change the install script, that com_contact will have different default permissions. That's doable.

avatar AlexRed
AlexRed - comment - 14 Apr 2017

Please @laoneo help me to change the install script, that com_contact will have Allowed "Edit Custom Field Value" default "permission" and help me to set the contact field for "Mail" by default. If we fix it for me we can keep contact custom field in Joomla 3.7.0.
But for me we need to hide in Joomla 3.7.0 the users custom field (like for the new router problems), the bugs 15194 and 13601 make it unusable. And restore it in Joomla 3.7.1 if we fix it.

avatar joeforjoomla
joeforjoomla - comment - 14 Apr 2017

@AlexRed proposed a quite dramatic solution... however i agree with him that the release can't take place until everything is stable. Me and other people can't understand why the RC1 and RC2 is going on to be released even if problems are still present. It's still not time of an RC at all!

avatar rdeutz
rdeutz - comment - 14 Apr 2017

because software is never bug free, you will never release anything when you wait till all problems are fixed

avatar AlexRed
AlexRed - comment - 14 Apr 2017

Nobody ever said that before release must be resolved all the know problems. But the most important yes. When the administrator active the user all the data in the profile custom field are erased, and also the user can't find the profile custom field in the edit profile page in control panel. For me make it unusable.
The other problems in custom field can remain (14049, 15173, 14377, 15294, ecc..)

avatar laoneo
laoneo - comment - 15 Apr 2017

@AlexRed the problem with com_users is that it behaves in many places totally different, then any other extension. Rewriting that takes a big amount of time.

avatar AlexRed
AlexRed - comment - 15 Apr 2017

Please @laoneo help me to change the install script, that com_contact will have Allowed "Edit Custom Field Value" default "permission" and help me to set the contact field for "Mail" by default.
About the com_users we can hide in Joomla 3.7.0 the users custom field (like for the new router problems) if rewriting that takes a big amount of time. And restore it in Joomla 3.7.1 or later if we fix it.

avatar mbabker
mbabker - comment - 15 Apr 2017

Please stop comparing the handling of the router to any other action. To be blunt, that decision was more politically driven than a code functionality decision. The fix for any issue is not "hide the feature and re-enable when working", that should only be an option considered for critically broken code and unless I'm mistaken this is not critically broken.

avatar laoneo
laoneo - comment - 15 Apr 2017

Agree @mbabker.

@AlexRed honestly I don't understand what you want to achieve. com_contact has that permission already, so there is no change needed.

avatar AlexRed
AlexRed - comment - 15 Apr 2017

Sorry for my bad english, now I try with some images to explain:

have Allowed "Edit Custom Field Value" default "permission"
default-mail

set "Mail" by default
default-mail

avatar Bakual
Bakual - comment - 15 Apr 2017

@laoneo I think he wants to have different default behaviors for the com_contact.mail and com_contact.contact contexts. Eg the mail one should be allowed to edit by default and the contact one should not.

But the way our permission system works, that is not something we can or even should do.

avatar laoneo
laoneo - comment - 15 Apr 2017

@Bakual I guess this is possible, with more sections in the access.xml file.

@AlexRed now I got the use case, you want to enable it initially for the Public user groups. It makes sense for first time users, but I'm not sure if this would be a good decision from security point of view.

avatar AlexRed
AlexRed - comment - 15 Apr 2017

and set "Mail" by default ?

avatar laoneo
laoneo - comment - 15 Apr 2017

That can be done, but when I would go to the contacts component, I personally would expect that custom fields are shown for the contacts by default and not the form. But this is my personal opinion.

avatar AlexRed
AlexRed - comment - 15 Apr 2017

can add new custom fields in the mail form is a fantastic solutions now. For me the users want it and it is not so simple to understand the we need to change the dropdown. All the users I ask to do a new contact form with some new field have failed.

avatar brianteeman
brianteeman - comment - 15 Apr 2017

And if you change the default to mail you will say
All the users i asked to do a new contact details with some new field have failed.

The problem is not what is the default. The problem is that switching the context is not obvious at all and is a new concept for Joomla so it is unfamiliar

avatar laoneo
laoneo - comment - 15 Apr 2017

What can we do to make it more obvious?

avatar brianteeman
brianteeman - comment - 15 Apr 2017

I really don't know. I've been thinking about it for a while.

The only thing i came up with (which is not great) is to display a message
at the top (below the filters) to indicate which context you are in and
that you can change it from the filter box. Something like the blue message
you get at the top of some of the option tabs.

(Not at my computer for a few hours to do a test mockup)

On 15 Apr 2017 10:05 a.m., "Allon Moritz" notifications@github.com wrote:

What can we do to make it more obvious?


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#14377 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8R3jDgp13_YqOHNpMzDG5x6iQ9Uvks5rwIhPgaJpZM4MT7QA
.

avatar AlexRed
AlexRed - comment - 15 Apr 2017

for example split out in TAB, like in the new Editor - TinyMCE settings for the 3 SET.
The 3 tab would be visible with the 3 options
Mail | Contact | Category

avatar brianteeman
brianteeman - comment - 15 Apr 2017

I am not convinced changing a drop down select to a tab is much better but it is more consistent with other UI patterns in Joomla.

avatar Bakual
Bakual - comment - 15 Apr 2017

I guess this is possible, with more sections in the access.xml file.

I fear that would break more stuff than it helps. And you still would have to set public to default for that section and action which really isn't something I would do. ACL should be denied by default in all cases, that's how ACL works.

avatar laoneo
laoneo - comment - 15 Apr 2017

I was talking about having different permissions per context and not just from component to the field.

avatar Bakual
Bakual - comment - 15 Apr 2017

I was talking about having different permissions per context and not just from component to the field.

That's how I understood you, yes. But it's not as easy as it may sound and would need several adjustments all around the (com_field) code to take care of that special case.

avatar laoneo
laoneo - comment - 9 May 2017

Please test #15915 which should fix that issue. At the end of the day it was not so a hard and opens the door for new possibilities.

avatar laoneo
laoneo - comment - 9 May 2017

Guess can be closed?

avatar Bakual Bakual - change - 9 May 2017
The description was changed
Title
[com_fields] Automatic Display in User Context makes no sense?
[com_fields] Automatic Display in User Context doesn´t apply in this context
Status Confirmed Closed
Closed_Date 0000-00-00 00:00:00 2017-05-09 15:22:43
Closed_By Bakual
avatar Bakual Bakual - close - 9 May 2017

Add a Comment

Login with GitHub to post a comment