You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by "Si Chen (JIRA)" <ji...@apache.org> on 2006/11/08 23:06:58 UTC

[jira] Closed: (OFBIZ-158) updateReturnItemsStatus service changing RETURN_COMPLETED items to RETURN_ACCEPTED

     [ http://issues.apache.org/jira/browse/OFBIZ-158?page=all ]

Si Chen closed OFBIZ-158.
-------------------------

    Resolution: Fixed

SVN r 431998 already took care of this.

> updateReturnItemsStatus service changing RETURN_COMPLETED items to RETURN_ACCEPTED
> ----------------------------------------------------------------------------------
>
>                 Key: OFBIZ-158
>                 URL: http://issues.apache.org/jira/browse/OFBIZ-158
>             Project: OFBiz (The Open for Business Project)
>          Issue Type: Bug
>          Components: order
>    Affects Versions: SVN trunk
>            Reporter: Leon Torres
>         Assigned To: Si Chen
>
> When updating a ReturnHeader to RETURN_ACCEPTED, a complex and elaborate SECA chain fires off:
> 1) updateReturnHeader:  ReturnHeader.statusId changes to RETURN_ACCEPTED
> 2) SECAS bound to updateReturnHeader fire off and perform business logic.
> 3) eventually one of the SECAs will change the ReturnItems to RETURN_COMPLETED
> 4) checkReturnComplete service sees that all ReturnItems are RETURN_COMPLETED and changes ReturnHeader.statusId to RETURN_COMPLETED
> 5) But the very last SECA to run, updateReturnItemStatus, messes everything up by changing the ReturnItem statuses to RETURN_ACCEPTED:
>      <eca service="updateReturnHeader" event="commit">
>          <condition-field field-name="statusId" operator="not-equals" to-field-name="currentStatusId"/>
>          <action service="updateReturnItemsStatus" mode="sync"/>
>      </eca>
> This breaks the Return system.
> This SECA seems extraneous and the service itself is dangerous since it could potentially change a RETURN_CANCELLED item to something else, which should be illegal.  I removed this SECA and it fixed the problem.  Can we remove this seca?  If not, why is it there?  It's throwing a wrench into the return flow.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira