•  
      request #2705 [SOAP] Inconsistency in the labels of the dynamically binded fields values
    Infos
    #2705
    Stéphane Bégaudeau (begaudeaus)
    2013-03-08 11:08
    2013-02-26 10:44
    1626
    Details
    [SOAP] Inconsistency in the labels of the dynamically binded fields values
    The latest version of the SOAP API is now returning the binding for a group of user just like any other binding for a SB/CB/MSB, which is GREAT but there is a small inconsistency with the labels of the binding for those users.

    1- Create a tracker with a field binded to a group of users.
    2- When you call the SOAP operation "getArtifact(...)", you will retrieve an artifact with the artifact field value for the field binded to the group of users matching the following pattern: "Full Name (username)".
    3- When you are retrieving the description of the field in question with "getTrackerFields", the possible values for the fields are using the following pattern "username".

    With the description of the field we now have for example in the potential values:
    bind_value_id = 137
    bind_value_label = begaudeaus

    With the artifact downloaded we have the value "Stephane Begaudeau (begaudeaus)".

    We could use "getUserInfo" to have the necessary information from the "bind_value_id" of the TrakerField to create the pattern "Full Name (username)" but it would involve one additional request for each potential value of the SB/CB/MSB.

    We could also say that if we have the following pattern "Full Name (username)" as a value, we try to match it with the potential TrackerFieldBindValue but now that SB/CB/MSB binded to a group of users are no longer different than any other kind of binding, we can't make the difference with any other statically binded field.

    So if we did try to match "Full Name(username)" and a potential value of "username", it would create a problem with a statically binded field with the following description:
    bind_value_id = 14982 (not matching any user info)
    bind_value_label = Sub Component (Tuleap)
    bind_value_id = 84567 (not matching any user info)
    bind_value_label = Tuleap

    If we receive an artifact with the value "Tuleap", we would match it to the value with the label "Sub Component (Tuleap)" and not "Tuleap". This use case may not be common, it may appear.

    The newly introduced decision of returning the values of the binding for fields binded to a group of users should return TrackerFieldBindValue with the same label as the ArtifactFieldValue from "getArtifact".

    The screenshot attached shows the inconsistency between "getArtifact" and "getTrackerFields".
    API
    development
    Empty
    • [ ] enhancement
    • [ ] internal improvement
    Mélanie Bats (mbats)
    Stage
    Manuel Vacelet (vaceletm)
    Closed
    2013-03-07
    Attachments
    Screenshot from Eclipse's Variables view/
    References

    Follow-ups

    User avatar
    I just merged the changes according to documentation below.

    We will update demo.tuleap.net tomorrow morning.

    • Status changed from Verified to Closed
    • Close date set to 2013-03-07
    User avatar
    I'm working on this (I attach the current state of WSDL).

    But this modification might have an impact on addArtifact/updateArtifact as well.
    As you can see in the WSDL, for those 2 methods, field_value can now be either [value => string, file_info => ArrayFileInfo, 'bind_value' => ArrayFieldValue]

    We aims to update addArtifact and updateArtifact to allow API to modify artifact list values with 'bind_value' and ID of the value (so it's consistent with the other part of the API were IDs are in use) with a fallback on value.
    Examples ('value' part of update/add artifact, field is a checkbox, a select box or a multiselect):
    getTrackerFields returns following possible values for this field:
    [
    ['bind_value_id' => 115, 'bind_value_label' => 'DB'],
    ['bind_value_id' => 120, 'bind_value_label' => 'GUI']
    ]

    # I want to set both values:
    ['field_value']['bind_value'][ ['bind_value_id' => 115, 'bind_value_label' => ''], ['bind_value_id' => 120, 'bind_value_label' => '']]

    # Backward compat:
    ['field_value']['value'] = 'DB,GUI'

    For OpenList it's slightly different as we should be able to add new values:
    # I want to reuse a value already defined (list available with getTrackerFields)
    ['field_value']['bind_value']['bind_value_id' => 130, 'bind_value_label' => '']]

    # I want to add a new value (for instance a new CC email address):
    ['field_value']['bind_value']['bind_value_id' => -1, 'bind_value_label' => 'john.doe@foobar.com']]

    One question remains open:
    - As of today, if I setup a list field bound to users and I select 'registered users' as group, getTrackerFields will returns the list of all users of the platform (up to 20'000 on todays largest deployments). I suspect it will have nasty impact on API performance. How could we address this issue ?

    User avatar
    Hi,

    >>>>>>>>>>>
    Hi, for the bind_value_label property of a user, we intend to return the shortname everywhere e.g. "begaudeaus".
    >>>>>>>>>>>
    Great!

    >>>>>>>>>>>
    As for the second issue of a missing bind_value_id property, we have decided to return an object when the field value is an object and the raw value otherwise. So in the case where the field value is a user, we will return an object with value and id properties; the value will be the user shortname.
    >>>>>>>>>>>
    If I understand things correctly, if I have a String/Float/Boolean, the FieldValue will contain as a value something like "a string", "3.14", "true" but if we have a SelectBox/Checkbox/MultiSelectBox the FieldValue would contain as a value an object like Value("bind_value_id"=141, "bind_value_label"="begaudeaus") / Value("bind_value_id"=96215, "bind_value_label"="Some Static binding")? If that's the case, it's good. For "basic" fields, we have the raw value and for fields with choices (SB/CB/MSB) we have an object containing the "label" and "id" of the choice in question.

    Regards,

    Stéphane
    User avatar
    dylan bowden (dylan)2013-02-27 10:09
    Hi, for the bind_value_label property of a user, we intend to return the shortname everywhere e.g. "begaudeaus".

    As for the second issue of a missing bind_value_id property, we have decided to return an object when the field value is an object and the raw value otherwise. So in the case where the field value is a user, we will return an object with value and id properties; the value will be the user shortname.

    Please let me know if that will suit your needs.
    User avatar
    dylan bowden (dylan)2013-02-26 11:26
    I have investigated this a bit further and now see two issues. One is a bug that needs to be fixed and the other is an enhancement.

    The fact that getTrackerFields() returns "begaudeaus" for the bind_value_label instead of "Stéphane Begaudeau (begaudeaus)" is a bug that we need to fix.

    Also, I agree that it makes sense for there to be a bind_value_id property in the field_value property of an artifact. We will discuss how best to implement this and get back to you.

    • Status changed from Acknowledged to Verified
    User avatar
    dylan bowden (dylan)2013-02-26 10:56
    Hello Stéphane,
    Thank you for providing all the details. I will attempt to reproduce this locally and get back to you on how we will fix this.

    Regards,
    Dylan

    • Status changed from New to Acknowledged
    • Assigned to changed from None to dylan bowden (dylan)