Likely REST User Create/Update bug/anomaly with regard to Location

Hi All,

I am seeing an issue in version 12.1.4.

There is a new-ish change to the API where "Location" is now available as a ProfileField named "core_Location" in addition to the Location user property.

When you CREATE a new User, the "core_Location" ProfileField input is ignored, and both are set using the Location user property.

Example REST params and resulting JSON:

[REST Params]
Username:robtest-deleteme1
Location:LOCATION
_ProfileFields_core_Location:CORE_LOCATION

[Resulting User Object]
{
    "User": {
        "Location": "LOCATION",
        "ProfileFields": [
            {
                "LocalName": "core_Location",
                "Label": "core_Location",
                "Value": "LOCATION"
            }
        ]
    }
}

But when you UPDATE an existing User, it does the opposite, and the "core_Location" ProfileField is used to set both the "core_Location" ProfileField and Location user property.

[REST Params]
Location:LOCATION
_ProfileFields_core_Location:CORE_LOCATION

[Resulting User Object]
{
    "User": {
        "Location": "CORE_LOCATION",
        "ProfileFields": [
            {
                "LocalName": "core_Location",
                "Label": "core_Location",
                "Value": "CORE_LOCATION"
            }
        ]
    }
}

My guess is that the Location field was migrated to become a ProfileField in later versions of Verint, and most likely the Location field exists only for backwards compatibility, but it looks like something went wrong with the implementation.

My workaround is to set it both on create an update, just to future-proof against future changes.

I also see these other new Profile Fields:

core_Birthday
core_Gender
core_Public Email
core_Language
core_Website

I haven't tested to see if any of these have the same issue.

Thanks.

Parents
  • These are actually not new, they have been around quite awhile, but how they were reprsented in the API was a bit off.  There were properties that basically just were setting the core_ version of the profile field.  There is a known issue around these already where it is not setting property.

    If you truly want to future proof your code,  only interact with them as profile fields with the exception of Public Email and Language.   The other properties are all being marked obsolete in the next version, and the correct way to interact with them is by using the the core_ based key in Profile Fields.

Reply
  • These are actually not new, they have been around quite awhile, but how they were reprsented in the API was a bit off.  There were properties that basically just were setting the core_ version of the profile field.  There is a known issue around these already where it is not setting property.

    If you truly want to future proof your code,  only interact with them as profile fields with the exception of Public Email and Language.   The other properties are all being marked obsolete in the next version, and the correct way to interact with them is by using the the core_ based key in Profile Fields.

Children