updateParams on custom fields

Enes,

If the field you are trying to update is not of source "db" then it is going to be "non-db" which means that the field does not actually exist in the database. As it is not a real field you would not be able to update data in it via any database query, which is what the function updateParams does. That is why the function does a check to ensure the field is of source "db" as any other value makes the function useless.

"non-db"-type fields are held in memory only - generally the values in there are set via a logic hook at read-time or by other code for display only. For example, the "account_name" field on the Contact record that can be seen in the cached vardefs and used in a record. This is not a field held in the database but the value is calculated when the record is retrieved by querying on the "account_id" value, which is held in the database.

What is your use case for updating the value in the specified field? Is it different to the above scenarios?

Thanks,

JH.

Enes,

Actually, I have re-read what you said and realise now that you are probably trying to set fields with a source of "custom_fields" rather than "non-db" so what I have put above probably doesn't apply.

I would still like to know the full use case you are trying to solve here though  You may want to check out how the save() function does this task in the ./modules/DynamicFields/DynamicField.php file as well

Thanks,

JH.

Hello John,

Yes you're right, I'm trying to set up custom_fields source field, here is the description of my field : 

[status_proc_c] => Array
(
    [labelValue] => Status Procuration
    [visibility_grid] => 
    [required] => 
    [source] => custom_fields
    [name] => status_proc_c
    [vname] => LBL_STATUS_PROC
    [type] => enum
    [massupdate] => 
    [no_default] => 
    [comments] => 
    [help] => 
    [importable] => true
    [duplicate_merge] => enabled
    [duplicate_merge_dom_value] => 1
    [audited] => 1
    [reportable] => 1
    [unified_search] => 
    [merge_filter] => disabled
    [pii] => 
    [calculated] => 
    [len] => 100
    [size] => 20
    [options] => case_status_procuration
    [default] => 
    [dependency] => 
    [id] => Casesstatus_proc_c
    [custom_module] => Cases
)

In fact my use case is the following : 

I have some tasks attached to a case bean, after save of each task, I need to know if they are all validated or rejected, then I will update a field in my Case Bean. I was doing that by saving the case, but it causes concurrent access with the current user from time to time.

That's why I want to use updateParams by setting the value directly in DB.

Regarding the DynamicFields.php file, I checked the save function but how can I apply such thing for my needs ? Should I write the same code ? 

Thanks in advance.

Best regards,

Enes

Enes,

You don't have to copy all the code but you should look at how DynamicField handles the fact that the core function only works on "source" => "db" field definitions. Effectively it temporarily (for the scope of the function call) changes that attribute to "db" from "custom_felds" like this

array_merge($field, array('source' => 'db'));

which is simply appending an attribute to the array thereby overwriting any original value. In that code the field defs array passed only seems to be altering that one attribute for the field in question.

I would think that you should be doing the same in your code so that updateParams works for your custom field.

Thanks,

JH.

Hello John,

As you explained it is working well, I have to change the source to db and there is no problem.

That's strange that we must find a workaround by ourself for a "simple" thing like that

Thanks a lot and have a nice day !

Enes

Hello John,

As you explained it is working well, I have to change the source to db and there is no problem.

That's strange that we must find a workaround by ourself for a "simple" thing like that

Thanks a lot and have a nice day !

Enes

Enes,

Glad you have it working

I agree that the original function should probably be able to handle both stock and custom fields - it wouldn't be a massive undertaking to make it work that way. Perhaps you should raise it as a feature request / enhancement.

Thanks,

JH.