1079 Results for the search: ""

@joebordes I totally agree that for _most_ it surely is... but in reality, especially larger institutions struggle to update in time, and would be extremely thankful for extension options.
So such an offering would be a big win in keeping Mautic attractive in that segment.

we have to keep moving
I don't think this is a useful way to spend the project's resources.

This should NOT slow us down at all - rather should it not only pay for itself, but also seriously cross-finance the actual core development
🙂

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!

Create FieldGroupEvent, with the following implementation:

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.

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.

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?

Hi @escopecz , I have looked over your notes and tested things see my feedback below.

I was not able get the 500 when I renamed the group even though I tested in production env. What does happen is that when you rename the group, it does not actually rename the group, what it does is actually just updates the entry in the database where all custom groups are listed.

What happened when I tested it is that the name of the group on the contact was not translated anymore, that is because the group itself still exists and containts the fields - just translation for it does not exist anymore.

Why you might have encountered the 500 is because of cache. This is fixable (see my plan below).

The reason un/publish feature is not fully utilized is because at the moment bundle is created in a way that it does not touch the lead or company templates when they render fields, this design allows us to have field group bumdle as standalone component that you can remove anytime.

If I would want to utilize that fully and not show inactive groups I would need to touch those templates. I suggest we remove it from the UI, but leave it in database for now.

I would disallow deletion of group if the fields are in the group and an ability to mass transfer fields from one group to another.

This is related to the fact that when you delete a group in this plugin you are not removing the group itself, but rather you remove translation for that group.

In regards to cache my idea is to clear the translations cache and then when you actually delete a group or rename it will show in the GUI when you refresh it, because translations cache will be regenerated.

The other option would be to completely disable the cache like its done for dev and test env. but I do not want to do that.

In addition to a simple text file, I also added openapi spec. so you can copy it in swagger editor and get a nice looking documentation.

Here are the tasks that I see need to be done in order to address issues you mentionted, let me know what you think:

Best, M.

Thanks for sharing this @lolcode - indeed this is why we think it's important to introduce such a service. Thanks for the other links, super helpful!

https://civicrm.org/esr , https://lab.civicrm.org/dev/release/-/blob/master/README.md

https://ubuntu.com/security/esm

https://civicrm.org/esr , https://lab.civicrm.org/dev/release/-/blob/master/README.md

https://ubuntu.com/security/esm

Hi @escopecz , thanks for the feedback. I will look into detail for each point, here is my take at the moment.

& 4. More investigation needs to be done here but what you described might be happening because translation string is generated based on the name you input. We could add ability to override the translation string. The second thing is in prod. env. translator loader is using cache, so that might be way you are experiancing some of the issues. When you rename or delete the group I would also clear the cache.

The idea of unpublish / publish feature initially was to enable user to hide the entire group from the GUI temporarly, but encountered some challenges with that so at the moment features only come to the effect when using an API. Meaning if the group is unpublished its not gonna show in the results. Why did I have issues with the feature from the GUI side I cannot remember anymore, but I will investigate and let you know.

Good point, although I have to say I am against doing this implicitly. I suggest we add ability to transfer fields from one group to another and only allow to delete group if there are no fields in that group. Does that sound reasonable?

Tests are here: < https://gitlab.com/adra-network/mautic-field-groups-plugin/-/tree/dev_mautic5/Tests?ref_type=heads >, perhaps you want me to add some?

API docs are here:< https://gitlab.com/adra-network/mautic-field-groups-plugin/-/tree/dev_mautic5/docs?ref_type=heads >, is there a better place / format to use?

As for the where to place the functionality. I think its best if this is a a separate core bundle, please do know that we would also need to extend stuff in CoreBundle, specifically here: app/bundles/CoreBundle/Translation/Translator.php and here: app/bundles/CoreBundle/Loader/TranslationLoader.php.

Not only is this morally the right thing to do for many reasons cited in the articles below, given Open Source Collective is based in California, as we grow as an organisation it could even be a legal requirement (see https://www.mossadams.com/articles/2024/04/ca-sb-1162-pay-transparency-act).

Even if that means setting one for different regions in the world (in the case that we decide this is a factor that should be considered in setting the rate) I still think we should provide bandings.

We could start very simply with factors like seniority of position and level of experience, for example, and set the baseline banding and then if we need to take into account a factor based on geographic location, perhaps use the Big Mac Index.

There's legislation in place / coming in soon about fair pay policies so we may also have to take into consideration but I'd rather we act positively because it's the right thing to do, than because we're legally forced to do so.

Some articles that might be good to read:

https://figures.hr/post/what-are-the-advantages-and-disadvantages-of-using-salary-bands
https://www.socialtalent.com/blog/recruiting/7-reasons-why-you-should-include-salary-range-in-your-job-postings

A definite +1 from me, thanks for submitting the proposal @domidc - I think we should pull this into an async discussion to accept once we have four votes rather than waiting for the next meeting, because it really is hampering a lot of our work and projects by not being able to use our CMS to its full potential.

I think it's going to be very important to be clear on scope, and also budget. We will likely need to purchase some commercial extensions in order to build a secure, optimised site so let's not lose sight of both the scope and the budget.

We should also see if we can't pull in some of the designers/site builders who were working on the visual side of the website from the community, too.