Uploaded image for project: 'OFBiz'
  1. OFBiz
  2. OFBIZ-7117

LookupAccount search screen 'Find' button redirect to Lookup Group

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: Trunk
    • Fix Version/s: 16.11.01
    • Component/s: party
    • Labels:
      None
    • Sprint:
      Community Day 3 - 2016

      Description

      How to reproduce :
      1) Go to a person party profile : i.e. https://localhost:8443/partymgr/control/viewprofile?partyId=admin
      2) Click on 'Create New' from the 'List Related Accounts' section
      3) Click on the 'Look up button' (for searching through the account party id)
      4) Notice the title of the pop-up : "Lookup Party with the role Account" and the limited number of result. Lookup Party with the role Account.
      5) Click on the 'Find' button (empty search)
      6) Notice the new title "Lookup Group" and the new set of result

      Root of the behaviour :
      In "ofbiz/applications/party/widget/partymgr/LookupScreens.xml", there is the definition of the "LookupAccount" screen. This screen is the pop-up showing up when you click on the 'Lookup button' . It includes two forms :

      <include-form name="lookupPartyGroup" location="component://party/widget/partymgr/LookupForms.xml"/>

      and

      <include-form name="listLookupPartyGroup" location="component://party/widget/partymgr/LookupForms.xml"/>

      The first one, is the one used for the search when you click on the 'Find' button. By looking at this form's code, we can see that its target is the "LookupPartyGroup" screen. So when you click on the 'Find' button, a different screen is loaded and the title and the behaviour of the pop-up is modified. This screen is composed from the two same forms than the original one.

      Solution ? :
      I don't know if it's possible to overload the target of a form when it's called but if it is possible, then we may call the same form with the target "LookupAccount". If not, I think we need to create another form with the target "LookupAccount".

      Thanks,
      Florian

        Activity

        Hide
        soledad Nicolas Malin added a comment -

        Yes, just I hadn't finish yet

        Show
        soledad Nicolas Malin added a comment - Yes, just I hadn't finish yet
        Hide
        soledad Nicolas Malin added a comment -

        It's work as well !
        Commited on trunk at revision 1761314
        thanks

        Show
        soledad Nicolas Malin added a comment - It's work as well ! Commited on trunk at revision 1761314 thanks
        Hide
        jacques.le.roux Jacques Le Roux added a comment -

        BTW should we not close?

        Show
        jacques.le.roux Jacques Le Roux added a comment - BTW should we not close?
        Hide
        jacques.le.roux Jacques Le Roux added a comment -

        Well done guys, thanks!

        Show
        jacques.le.roux Jacques Le Roux added a comment - Well done guys, thanks!
        Hide
        soledad Nicolas Malin added a comment -

        OK not backport, my correction didn't work on stable branch

        Show
        soledad Nicolas Malin added a comment - OK not backport, my correction didn't work on stable branch
        Hide
        soledad Nicolas Malin added a comment -

        Commited on trunk at revision 1761257, I will check if will need to backport

        Show
        soledad Nicolas Malin added a comment - Commited on trunk at revision 1761257, I will check if will need to backport
        Hide
        soledad Nicolas Malin added a comment -

        Thanks Florian,
        I found a solution to solve the problem.
        The reason as you spotted come from to use a generic form called by a screen who prepare some search parameters. To resolve it, I changed the target on generic form to a dynamic resolution form context.

        The last URI called is present on parameters.thisRequestUri, so when you rerun the serach by the form I recall correctly the good LookupScreen.

        Show
        soledad Nicolas Malin added a comment - Thanks Florian, I found a solution to solve the problem. The reason as you spotted come from to use a generic form called by a screen who prepare some search parameters. To resolve it, I changed the target on generic form to a dynamic resolution form context. The last URI called is present on parameters.thisRequestUri, so when you rerun the serach by the form I recall correctly the good LookupScreen.
        Hide
        Florian M Montalbano Florian added a comment -

        While searching for the source of this behaviour, I found this condition construction in FindLookUp.groovy :

        exprList = [EntityCondition.makeCondition("statusId", EntityOperator.NOT_EQUAL, "PARTY_DISABLED")
                    , EntityCondition.makeCondition("statusId", EntityOperator.NOT_EQUAL, null)];
        CondList = EntityCondition.makeCondition(exprList, EntityOperator.AND);
        CondList1 = EntityCondition.makeCondition("statusId", EntityOperator.EQUALS, null);
        statusPartyDisable = EntityCondition.makeCondition([CondList1, CondList], EntityOperator.OR); 
        

        which corresponds to :
        A : ( statusId != null AND statusId != "PARTY_DISABLED" ) OR ( statusId == null )
        I think it could be simplified to :
        B : ( statusId != "PARTY_DISABLED ) OR ( statusId == null )

        The logic result seems to be the same for all the case :
        statusId = null => : A = true; B = true
        statusId = "PARTY_DISABLED" => A = false; B = false
        statusId != null && statusId != "PARTY_DISABLED" => A = true; B = true;

        What do you think of it ?

        Show
        Florian M Montalbano Florian added a comment - While searching for the source of this behaviour, I found this condition construction in FindLookUp.groovy : exprList = [EntityCondition.makeCondition( "statusId" , EntityOperator.NOT_EQUAL, "PARTY_DISABLED" ) , EntityCondition.makeCondition( "statusId" , EntityOperator.NOT_EQUAL, null )]; CondList = EntityCondition.makeCondition(exprList, EntityOperator.AND); CondList1 = EntityCondition.makeCondition( "statusId" , EntityOperator.EQUALS, null ); statusPartyDisable = EntityCondition.makeCondition([CondList1, CondList], EntityOperator.OR); which corresponds to : A : ( statusId != null AND statusId != "PARTY_DISABLED" ) OR ( statusId == null ) I think it could be simplified to : B : ( statusId != "PARTY_DISABLED ) OR ( statusId == null ) The logic result seems to be the same for all the case : statusId = null => : A = true; B = true statusId = "PARTY_DISABLED" => A = false; B = false statusId != null && statusId != "PARTY_DISABLED" => A = true; B = true; What do you think of it ?

          People

          • Assignee:
            soledad Nicolas Malin
            Reporter:
            Florian M Montalbano Florian
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development

                Agile