PM81585: [wi 248636] Resource allocation percentage calculation is wrong when team area is involved

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error description

  • How to reproduce the issue:
    1. create a Project are based on formal process template.
    2. Create team area in the project area.
    3. Add a user (say User 1) to both the project area and team
    area.
    4. Open the user editor for 'User 1' and set the work
    environment, resources allocations as 50% for Project area and
    30% for team area.
    5. Create a Plan with owner as Project area and Release 1.0 as
    iteration. Set the 'Include all Items' to true.
    6. switch to the Resources tab on the plan editor and delete the
    user for the project area and save the plan using the delete
    button at the user level not the allocation level.
    7. Refresh the plan after removing. It shows a warning that the
    user is not part of the plan owner and also the team area
    membership and allocation will not be deleted.
    8. Add a new allocation with for one day with 50% allocation.
    9. the save fails saying that the user is over allocated by
    130%.
    
    https://jazz.net/jazz/web/projects/Jazz%20Support%20%28Private%2
    9#action=com.ibm.team.workitem.viewWorkItem&id=248430
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED:                                              *
    ****************************************************************
    * PROBLEM DESCRIPTION:                                         *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    1.) When removing a user from the "plan owner" process area,
    the existing allocations for that user in the process area
    were not being deleted.  This is now happening server-side
    and will remove allocations for the user in question from
    the process area before removing the user.
    2.) When adding an allocation for the team area in step 8
    and 9 in the description, the user was actually being added
    back in to the project area, as there was a member check
    happening for the plan owner regardless of the assignment
    being added.  This caused the orphaned allocation to be used
    in the calculation as seen in step 9 in description -
    because the transaction failed, the addition of the user to
    the project area was rolled back and this detail was not
    seen by the user.  Updated this to only attempt to add a
    member to the plan owner process area if one of the
    assignments being added is for the plan owner.
    3.) The RemoveUserAction was attempting to walk through the
    children of the user entry and delete allocations - this was
    failing every time and causing an exception that resulted in
    an assertion failed error in the console.  When running in
    debug mode, this issue caused the action to fail
    consistently, making this issue a little difficult to debug
    at first.  I've disabled the call to removeAllChildren, and
    if we have a reason to revisit we can open a separate defect
    to fix it - as of now I see no purpose for it so a likely
    follow-up will be to remove the method altogether.
    

Problem conclusion

  • 1.) When removing a user from the "plan owner" process area,
    the existing allocations for that user in the process area
    were not being deleted.  This is now happening server-side
    and will remove allocations for the user in question from
    the process area before removing the user.
    2.) When adding an allocation for the team area in step 8
    and 9 in the description, the user was actually being added
    back in to the project area, as there was a member check
    happening for the plan owner regardless of the assignment
    being added.  This caused the orphaned allocation to be used
    in the calculation as seen in step 9 in description -
    because the transaction failed, the addition of the user to
    the project area was rolled back and this detail was not
    seen by the user.  Updated this to only attempt to add a
    member to the plan owner process area if one of the
    assignments being added is for the plan owner.
    3.) The RemoveUserAction was attempting to walk through the
    children of the user entry and delete allocations - this was
    failing every time and causing an exception that resulted in
    an assertion failed error in the console.  When running in
    debug mode, this issue caused the action to fail
    consistently, making this issue a little difficult to debug
    at first.  I've disabled the call to removeAllChildren, and
    if we have a reason to revisit we can open a separate defect
    to fix it - as of now I see no purpose for it so a likely
    follow-up will be to remove the method altogether.
    

Temporary fix

Comments

APAR Information

  • APAR number

    PM81585

  • Reported component name

    RATL TEAM CONCE

  • Reported component ID

    5724V0400

  • Reported release

    400

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2013-01-28

  • Closed date

    2013-06-18

  • Last modified date

    2013-06-18

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

  • Fixed component name

    RATL TEAM CONCE

  • Fixed component ID

    5724V0400

Applicable component levels

  • R400 PSN

       UP



Rate this page:

(0 users)Average rating

Document information


More support for:

Rational Team Concert

Software version:

4.0

Reference #:

PM81585

Modified date:

2013-06-18

Translate my page

Machine Translation

Content navigation