.webp)
.webp)
45 Results for the search: "#5"
Proposals 16
View all (16)
Events 5
View all (5)Debates 3
Posts 10
Paid position (22 week contract) Senior Developer for Mautic Campaign Library Phase 2 Project
Senior Developer (Fixed term position for 12 months with view to ongoing permanent role)
Update: Mautic 5.2 UX/UI
[Closed] Paid position (6 month contract) Senior Developer for Mautic Campaign Library Phase 1 Project
Participants 1
Comments 10
I totally love the overall approach, and we already have a cardboard version of the refined Mautibot at our office!!!
My personal opinion is that this does not have to be final, though. The idea of having a "styleguide" or "construction kit" sounds great to me (https://github.com/mautic/low-no-code/issues/31#issuecomment-2950272959)
In particular, I would not understand this voting as "Flavor #5 has to be used for error messages" - rather still be open to more positive and fun variations.
I totally love the overall approach, and we already have a cardboard version of the refined Mautibot at our office!!!
My personal opinion is that this does not have to be final, though. The idea of having a "styleguide" or "construction kit" sounds great to me (https://github.com/mautic/low-no-code/issues/31#issuecomment-2950272959)
In particular, I would not understand this voting as "Flavor #5 has to be used for error messages" - rather still be open to more positive and fun variations.
Hi all, unfortunately we had no community attendees for the demo at the meeting so having waited for 5 or so minutes we drew to a close. If you would like to see the demo please leave a message here and I will pick up with you. Thank you, DJ
Hi all, unfortunately we had no community attendees for the demo at the meeting so having waited for 5 or so minutes we drew to a close. If you would like to see the demo please leave a message here and I will pick up with you. Thank you, DJ
Thanks for sharing your thoughts @joebordes - to be clear, right now we do not support a minor release after the next minor release is made (e.g. when 5.2 comes out, 5.1 is no longer supported), and a major release is supported for 3 months after the next major release. We do a new major release on average, every 12-18 months.
Currently we don't have any LTS release, in the traditional sense. Just an 'actively supported' version.
You can find the timings we currently have at https://www.mautic.org/mautic-releases - we are planning to extend the support that we offer as our core security support to 3 and 6 months respectively, however for many businesses who have tens or hundreds of instances to update even this isn't enough time. They need security releases for Mautic for a while longer, so that they can safely update all their instances while remaining compliant.
That's why we're proposing to offer this (paid) service, which will also be a revenue stream for the project.
I hope that gives a bit more context!
Thanks for sharing your thoughts @joebordes - to be clear, right now we do not support a minor release after the next minor release is made (e.g. when 5.2 comes out, 5.1 is no longer supported), and a major release is supported for 3 months after the next major release. We do a new major release on average, every 12-18 months.
Currently we don't have any LTS release, in the traditional sense. Just an 'actively supported' version.
You can find the timings we currently have at https://www.mautic.org/mautic-releases - we are planning to extend the support that we offer as our core security support to 3 and 6 months respectively, however for many businesses who have tens or hundreds of instances to update even this isn't enough time. They need security releases for Mautic for a while longer, so that they can safely update all their instances while remaining compliant.
That's why we're proposing to offer this (paid) service, which will also be a revenue stream for the project.
I hope that gives a bit more context!
My suggestion;
Put everything into LeadBundle (db entity, api endpoints, standard controllers for gui).
Dispatch event LeadEvents::FIELD_GROUP_LIST_ON_GENERATE before displaying (in controller most likely) for the following templates:
https://gitlab.com/adra-network/mautic-field-groups-plugin/-/tree/main/Views/Company?ref_type=heads
https://gitlab.com/adra-network/mautic-field-groups-plugin/-/blob/main/Views/Field/list.html.php?ref_type=heads
https://gitlab.com/adra-network/mautic-field-groups-plugin/-/tree/main/Views/Lead?ref_type=heads
Dispatch the event also when building configuration form (inside form type class?):
Create FieldGroupEvent, with the following implementation:
groups: array[string -> displayValue, string -> uniqueId]
getGroups()
setGroups()
Change the templates so groups are used without hardcoding any translation strings.
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
Elemnets we do not need anymore:
We do not need this: https://gitlab.com/adra-network/mautic-field-groups-plugin/-/blob/main/Form/Type/FieldGroupExtensionType.php?ref_type=heads (since we will adjust the type in the core).
We do not need this anympre: https://gitlab.com/adra-network/mautic-field-groups-plugin/-/tree/dev_mautic5/Translation?ref_type=heads (since field groups will have nothing to do with the translations when we are done)
Let me know if you are OK with this approach or is there something you would like to change / add. Thank you.
My suggestion;
Put everything into LeadBundle (db entity, api endpoints, standard controllers for gui).
Dispatch event LeadEvents::FIELD_GROUP_LIST_ON_GENERATE before displaying (in controller most likely) for the following templates:
https://gitlab.com/adra-network/mautic-field-groups-plugin/-/blob/main/Views/Field/list.html.php?ref_type=heads
https://gitlab.com/adra-network/mautic-field-groups-plugin/-/tree/main/Views/Lead?ref_type=heads
Create FieldGroupEvent, with the following implementation:
getGroups()
setGroups()
Change the templates so groups are used without hardcoding any translation strings.
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
Elemnets we do not need anymore:
We do not need this: https://gitlab.com/adra-network/mautic-field-groups-plugin/-/blob/main/Form/Type/FieldGroupExtensionType.php?ref_type=heads (since we will adjust the type in the core).
We do not need this anympre: https://gitlab.com/adra-network/mautic-field-groups-plugin/-/tree/dev_mautic5/Translation?ref_type=heads (since field groups will have nothing to do with the translations when we are done)
Let me know if you are OK with this approach or is there something you would like to change / add. Thank you.
Share