So I have been dealing with multiselects in logic hooks.
Here is the wonderful stuff I have to deal with:
When multiselect values are sent, they look something like this:
^option_1^,
^option_2^,
^option_5^
That in and of itself is the way a first-grader would code. One would rationally thing that a developer with a modicum of intelligence and a somewhat low level of retardation would send that through as a formal array.
But here it gets even worse.
When you have a field on a form, and you select nothing for that multiselect field, it sends through “^^” instead of nothing (an empty array).
That means one cannot use:
if(!empty($multiselectvalues)) {
// do something
}
It will run what is inside that if statement.
Again, if the person who came up with that used their brain for 3 seconds flat, they would be using an array, or if impossible, have middleware that transforms that to a formal array inbetween.
Guys, simple, small companies like EspoCRM are kicking your butt on simple stuff. Need I say something simple like “vardefs suck” to bolster my point.
Use it, don’t use it.
It is easily turned into an array with a single preg_replace command.
Your condition can be written something like this
if($multiselectvalues) != '^^') {
// do something
}
All of this is easier to solve than to write the nasty things you wrote.
I encourage you to drop SuiteCRM and to move on to other communities where things are better done, to match your obviously superior intelligence.
1 Like
For anyone to take benefit from this post… There are two global util functions that already handles this:
One that converts an string to an array:
unencodeMultienum($string)
And obviously the opposite:
encodeMultienumValue($arr)
Edit: At least for SutieCRM 7. It probably exists in SuiteCRM8 too.
1 Like
My point is that this is remedial programming from the start.
I (and nobody) should not have to jump through hoops to transform data that should not be in that form in the first place.
Why fork a project at all if you are not doing it to remove legacy junk?
“jump through hoops”… it took me 30 seconds to search the code base for ^^ and see how it’s handled in the code, I can just grab their way of unpacking into an array and use it.
And it’s one line long. It’s not easy to suggest something smaller and more straight-forward than one line. It’s possible, code can be cleaner, more readable, more performant, etc. but I don’t think this cries for indignation, sorry.
And remember that there might be many other contraints that you’re not seeing at all. One that people often forget with SuiteCRM is that there are a ton of slow-moving add-on developments, and customizations out there. The less you change, the less you break. I don’t know if that is what happened here, but sometimes you’re developing, and you’re thinking “I will just fit this all in here as text so that it doesn’t become backwards-incompatible with X. I shouldn’t touch the DB structure or the vardefs for this”.
Why fork a project at all if you are not doing it to remove legacy junk?
Fork it, remove all the legacy junk, and you will learn by the time you’re 110 years old and you’re only half-way through it…
Think: 10 years of developments with 100 devs; then forked by a small company that typically has 2 or 3 devs working on it… with a huge community giving them new work, not just waiting for them to finish up old work…