Propose new Mautic features
#MauticRoadmap Building Mautic together!
Has your proposal been discussed on the Mautic Forums already?
Yes, multiple times. Here is a thread with one of the most recent replies: https://forum.mautic.org/t/merge-custom-fields-group-bundle-to-mautic-core/28960/4
Is your feature request related to a problem? Please describe.
Some Mautic users, would like to have additional field groups as opoose to just the default ones.
Describe the solution you'd like
At the moment you can add additional field groups by doing some coding. I would like to eliminate the coding part, I want user to be able to add additional field groups into Mautic without a need for a developer.
Describe alternatives or workarounds you've considered
An alternative to this bundle is that you extend the form type, but you need to hire a developer to handle that for you.
Additional context
As an author of the plugin, I can say that it felt like plugin really helped out some people and provided a much needed feature.
I would also like to point out that the plugin works and most of the work has already be done, so I can start with the merging to core pretty quickly.
I would kindly ask the team, in the event that this actually passes the proposal stage, that someone answers to my questions expressed in the forum post here: < https://forum.mautic.org/t/merge-custom-fields-group-bundle-to-mautic-core/28960/4?u=mzagmajster >.
Thank you.
Does this issue could impact on users private data?
No, I do not think so.
Funded by
Project funded by Adra Cloud, coded and maintained by Matic Zagmajster
Estimated cost
It'd be great to try to get this into the 5.2 release, if it's not a BC Break.
Project funded by Adra Cloud, coded and maintained by Matic Zagmajster.
This proposal has been accepted because:
Thanks for all the discussion and debate, this feature will be great to bring into Mautic.
Proposal appearing in these projects:
Report inappropriate content
Is this content inappropriate?
Comment details
You are seeing a single comment
View all comments
Conversation with John Linhart
All of it sounds good!
The only thing I don't understand is the translation and cache. Why do we use translation for user-generated strings? We don't do that in other parts of Mautic, right? How would users translate the groups names if the group names should be translatable?
And, do we need aliases? IDs aren't good enough?
So the way core field groups are done now is with the translations. Esentially you have something like this:
[
'mautic.lead.field.group.core' => 'core',
'mautic.lead.field.group.social' => 'social',
'mautic.lead.field.group.personal' => 'personal',
'mautic.lead.field.group.professional' => 'professional'
]
You see the key in the above array is actually translation string, so when I was writing this plugin I tried to build it in a way so that it does not against existing code base, and instead tries to reuse as much as possible and does not touch things you do not absolutely have to touch. If I would not use translation approach I would have to modify templates as well where these groups are used.
So when you enter the field group in the plugin form, plugin actually takes what you enter as a display name and behind the scenese generates translation string similar to the ones you see above.
How would users translate the groups names if the group names should be translatable?It is true that at the moment you can only add one translation for the group, but if there is interest we could add ability to the plugin to add more the one translation. That being said, I am not sure this adds much value since you do not really translate the field groups (by that logic you would also want to translate the custom fields labels, you just do not).
And when we use translations we also use translation cache, that is why the tasks related to cache were listed above.
And, do we need aliases? IDs aren't good enough?Alias is something that I took from custom fields :), but I guess, I could make it work with the IDs (would have to check though, to not have any surprises). So it would look something like:
[
'mautic.lead.field.group.1' => '1',
]
Thanks for the suggestion. One thing to keep in mind is that when you reference field groups in custom plugins for example, like when you update the field, the code is easier to read if you have some descriptive name as oppose to just an ID (but that is just from the perspective of development of custom functionality).
For example:
$lead->getFieldValue('countryiso, 'mygroup');
looks way better, then:
$lead->getFieldValue('countryiso, '1');
Updated tasks based on your notes:Clear cache on newStandard, editStandard, deleteStandard or disable cache completely (not a good idea)
Remove the publish/unpbulish feature from GUI
Allow to transfer fields from one group to another
Only allow to delete a group if no fields are in the group (also display number of fields in the group)
Update Tests
Do we use translation approach (and do not touch lead/company templates, but we need to take care of the cache) or do we leave the translations out and update the templates?
My personal take is that I do not mind touching templates, but we should use some sort of cache to load this records due to performance, since field groups is something you typically setup once and then just use it, I do not think field groups change that often.
But I will do, what you decide is best :).
We are going deeper into the implementation details, but I'd suggest to dispatch events in the core code where you need them for your plugin to work without any hacks. For example I'm looking at https://gitlab.com/adra-network/mautic-field-groups-plugin/-/blob/main/EventListener/CustomTemplateSubscriber.php?ref_type=heads and this would be a no go that a plugin is replacing core templates with some other. This will eventually break things and it will be hard to debug.
In https://gitlab.com/adra-network/mautic-field-groups-plugin/-/blob/main/Model/FieldGroupModel.php?ref_type=heads I can see that you translate all groups. Why not translate only the default ones?
On the main branch, there is Mautic 4 version of this plugin, and there was a change to the approach in Mautic 5 version, so lets just look into that and leave out the old version:
https://gitlab.com/adra-network/mautic-field-groups-plugin/-/tree/dev_mautic5
I overrided the translation loader, the coresponding configuration form type (and some templates in Mautic 4) to actually get this plugin to work. Ideally if we are talking about merging to core I would not override as much as I would replace the classes that need to replaced, same goes for the templates. If any modification would be needed I would update the core templates not override via plugin.
Why am I translating all the groups?
Because Mautic core dictates the pattern that field groups need to follow in order to show propely in the UI (somewhere in templates and forms translation string base is hardcoded).
Honestly if you are willing to put an additional event into the core and dispatch it at the right places that would be one of the better ways to handle this and I do not think we need to override any translators.
Loading comments ...