Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: Upcoming Release
    • Component/s: None
    • Labels:
      None

      Description

      We have enabled flag in ServiceEcaRule class, if its set false then seca rule will not be execute.
      But there is not way to disable seca.

      We can add enabled flag in SECA definition to disable the existing seca rule.
      Here is the proposal:

      • Add new attribute on seca tag named enabled
      • Default value will be true for this.
      • If user want to disable existing OOTB seca rule, then user can define same rule in custom component and set the enabled=false
      • Need some changes in code to honor the enabled attribute while loading seca rule.

      Also as per current flow if same seca rule is define more then once, system will execute all the rule, ideally it should not execute same rule (same rule, condition and action) if its defined more than one.

        Activity

        Hide
        jacques.le.roux Jacques Le Roux added a comment -

        Hi Deepak,

        This patch looks good to me, any reason why it's not committed?

        Show
        jacques.le.roux Jacques Le Roux added a comment - Hi Deepak, This patch looks good to me, any reason why it's not committed?
        Hide
        mbrohl Michael Brohl added a comment -

        +1

        Show
        mbrohl Michael Brohl added a comment - +1
        Hide
        deepak.dixit Deepak Dixit added a comment -

        Thanks Jacques and Michael for review, I have to verify one more scenario, once it verified I'll commit it.
        I'll try to commit it tomorrow.

        Show
        deepak.dixit Deepak Dixit added a comment - Thanks Jacques and Michael for review, I have to verify one more scenario, once it verified I'll commit it. I'll try to commit it tomorrow.
        Hide
        deepak.dixit Deepak Dixit added a comment -

        This has been committed at ofbiz framework trunk at r#1812394

        I was stuck on use case where same service in being called with different parameter.
        Eg.

        <eca service="createPartyRelationship" event="invoke">
            <set field-name="partyId" env-name="partyIdFrom"/>
            <action service="ensurePartyRole" mode="sync"/>
        </eca>
        <eca service="createPartyRelationship" event="invoke">
            <set field-name="partyId" env-name="partyIdTo"/>
            <action service="ensurePartyRole" mode="sync"/>
        </eca>
        

        In this case Seca rule is same, condition is same and action is same but we are passing different in parameter, in first rule partyId will be partyIdFrom and in second case it will be partyIdTo.

        But good news is we don't have this kind of rule,
        if we have this kind of rule we can use condition to make sure partyIdFrom/To (or any param that we are setting in set field) is not empty to make them unique.

        Show
        deepak.dixit Deepak Dixit added a comment - This has been committed at ofbiz framework trunk at r#1812394 I was stuck on use case where same service in being called with different parameter. Eg. <eca service= "createPartyRelationship" event= "invoke" > <set field-name= "partyId" env-name= "partyIdFrom" /> <action service= "ensurePartyRole" mode= "sync" /> </eca> <eca service= "createPartyRelationship" event= "invoke" > <set field-name= "partyId" env-name= "partyIdTo" /> <action service= "ensurePartyRole" mode= "sync" /> </eca> In this case Seca rule is same, condition is same and action is same but we are passing different in parameter, in first rule partyId will be partyIdFrom and in second case it will be partyIdTo. But good news is we don't have this kind of rule, if we have this kind of rule we can use condition to make sure partyIdFrom/To (or any param that we are setting in set field) is not empty to make them unique.

          People

          • Assignee:
            deepak.dixit Deepak Dixit
            Reporter:
            deepak.dixit Deepak Dixit
          • Votes:
            2 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development