Last Active
Preferred Name
  • Export Custom Field Data

    Hello & welcome to the community :smiley:

    This one can be a bit tricky because the data is serialized, but if you only need to pull out a few fields at a time there is a way:

    SELECT (CASE WHEN (@find := LOCATE('s:3:"001";s', gibbonPerson.fields)) > 0 THEN REPLACE(LEFT( @var := SUBSTRING(gibbonPerson.fields, @find + 15), LOCATE('";', @var)-1), '"', '') ELSE '' END) AS `Your Custom Field` FROM gibbonPerson

    What this will do is extract a single value by locating the start and end of the string (with a couple variables to help). You can add this statement as part of any query on the gibbonPerson table to get custom field values.

    The important part of the above statements is s:3:"001", where the 001 is the ID of the custom field. When you're editing the custom field in Gibbon you can see the ID number in the url bar as gibbonPersonFieldID=001. If you need a different custom field you can replace the 001 with the ID of the field you need. You can repeat this statement if you need to pull out a few different custom fields, just change the ID value for each one (and the `Your Custom Field` part).

    Hope this helps! I think it would certainly be great if Query Builder had a way to pull out this data built-in, it's possibly something we can look into.
  • Cutoff date in data update settings

    Yep, this sounds like normal behaviour, the goal for the redirect is to encourage all users to update their data. If they've never submitted an update then they'll be redirected along with any users who haven't submitted one after the cutoff.
  • addNumber breaks liveValidation in some cases

    Hi Roman,

    I tested out your code and discovered the error luckily isn't with LiveValidation, which as you noted seems to be working and prevents submission, but happens to be a css rule that was added to help fix an issue with overlapping validation messages inside a phone number:
    input[name*="phone"] ~ .LV_invalid

    Incidentally, the Form class does have specialized phone number inputs for this case, rather than using addNumber('phone'). As it so happens, we've made some pretty major changes to the form rendering in v18, and this issue appears to no longer exist for the upcoming version.