You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@syncope.apache.org by "Laszlo Miklosik (JIRA)" <ji...@apache.org> on 2017/05/31 12:52:04 UTC

[jira] [Created] (SYNCOPE-1102) Syncope 1.1.5 unique attribute update inserts additional value

Laszlo Miklosik created SYNCOPE-1102:
----------------------------------------

             Summary: Syncope 1.1.5 unique attribute update inserts additional value
                 Key: SYNCOPE-1102
                 URL: https://issues.apache.org/jira/browse/SYNCOPE-1102
             Project: Syncope
          Issue Type: Bug
    Affects Versions: 1.1.5
            Reporter: Laszlo Miklosik


To reproduce:

- make sure you have a unique attribute in the Syncope schema (e.g. called privateEmailAddress)
- create a user via POST and use value 'a@gmail.com' for this unique attribute
- then try to update this via the Syncope REST API and to change it into 'b@gmail.com' (by using the below POST payload):
{code}
{
  "attributesToBeUpdated": [
    {
      "schema": "privateEmailAddress",
      "valuesToBeAdded": [
        "b@gmail.com"
      ],
      "valuesToBeRemoved": [
        "a@gmail.com"
      ]
    }
  ]
}
{code}
- after this the Syncope MySQL data gets incorrect (the unique attribute will have 2 values in table UAttrUniqueValue) and you cannot e.g. delete anymore the user.

- You then can find the old unique attribute value using query:

{code}
select min(id) from UAttrUniqueValue group by ATTRIBUTE_ID having count(stringValue) > 1
{code}

and you can fix the Syncope data inconsistency by deleting the related row from UAttrUniqueValue.

- Root cause comes from line 467:

{code}
                for (Long attributeValueId : valuesToBeRemoved) {
                    attributeValueDAO.delete(attributeValueId, attrUtil.attrValueClass());
                }
{code}
where the delete call uses the same argument values in case of both the non-unique and unique attributes, this in fact a non-unique attributes is tried to be deleted.

Note: as UserMod payloads are not used anymore in Syncope 2 REST API, it's likely that this issue is not happening on Syncope 2, but might reproduce on Syncope 1.1.6-1.2.10.

Note: I have a patch I applied in our overlay and can provide it if necessary.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)