ofbiz-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacques Le Roux (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OFBIZ-7959) Enable the status selection for WorkEffort duplication
Date Wed, 31 Aug 2016 13:08:20 GMT

    [ https://issues.apache.org/jira/browse/OFBIZ-7959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15452194#comment-15452194

Jacques Le Roux commented on OFBIZ-7959:

I can answer to both of you at the same time. Yes, it's not a problem the only thing it does
is indeed increasing the sequence id and, apart if you have constraint on serialised (not
discontinued) workEffortIds, that should not be a problem. I mean in case you like to play
with the F5 touch ;).

BTW sequenced-id-prefix element in minilang does the same but indeed in a transaction. So
If we want to be totally secure it should be better in a service. This to avoid possible already
used (in the meantime) workEffortIds, hence an entity creation rejection. But let's face it,
you can put what you want there anyway. So I don't see that as a big deal, only a convenient
way for users, if it fails try a new one, this can happen anyway...

> Enable the status selection for WorkEffort duplication
> ------------------------------------------------------
>                 Key: OFBIZ-7959
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-7959
>             Project: OFBiz
>          Issue Type: Improvement
>          Components: workeffort
>    Affects Versions: Trunk
>            Reporter: Montalbano Florian
>            Assignee: Nicolas Malin
>            Priority: Minor
>              Labels: duplicate, status, workeffort
>         Attachments: OFBIZ-7959.patch, OFBIZ-7959.patch, OFBIZ-7959.patch
> It is possible to duplicate workeffort in the WorkEffort component (https://localhost:8443/workeffort/control/EditWorkEffort?workEffortId=9000)
but the duplicated WorkEffort keeps the same status than the original one. So when you duplicate
a cancelled task, it is locked in the same state.
> We could adapt this service to allow the selection of the status for the new workeffort.
Of course, you should be able to select only status that are relevant to the workeffort type.

> A first solution is to get the currentStatusId of the workeffort to duplicate. Then we
can access to the linked statusTypeId. So we can retrieve all status relevant and order them
by sequenceId (that way the default value is the first statuts of the sequence : created for
the task).

This message was sent by Atlassian JIRA

View raw message