Labels |
Added:
?
|
Idea from a nondev :) can the showon parameter help?
Title |
|
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.
Category | ⇒ | com_fields com_users |
Title |
|
Category | com_fields com_users | ⇒ | com_fields com_users UI/UX |
Status | New | ⇒ | Confirmed |
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.
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.
Fantastic, can your fix hide the "Automatic Display" parameter only in user and contact field ?
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.
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 :)
You can change the install script, that com_contact will have different default permissions. That's doable.
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.
@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!
because software is never bug free, you will never release anything when you wait till all problems are fixed
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..)
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.
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.
@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.
and set "Mail" by default ?
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.
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.
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
What can we do to make it more obvious?
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
.
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
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.
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.
I was talking about having different permissions per context and not just from component to the field.
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.
Guess can be closed?
Title |
|
||||||
Status | Confirmed | ⇒ | Closed | ||||
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-05-09 15:22:43 | ||||
Closed_By | ⇒ | Bakual |
Difficult to solve.