Menu

#876 Advanced Zoom and RelationTypes

Core
closed-accepted
3
2010-04-11
2009-11-13
No

Current Zoom (class AZoomAcross) allows to zoom from one record to a destination record only if the destination table references the source table.

For example you can zoom from an Order to an Invoice only if the Invoice references the order in its invoice header.

Enter advanced zoom:
With advanced zoom you can define a rule (a relation type) that finds all relevant invoices for a given order via order->orderLines->invoiceLines->invoice. And it works in both directions.

The old zoom (just via foreighn key references) still works

Discussion

1 2 > >> (Page 1 of 2)
  • Trifon (An ADempiere founder)

    Hi Tobias,

    sounds very good!
    [1+] to integrate it in trunk.

    Regards,
    Trifon
    www.catura.de

     
  • Antoni Ten

    Antoni Ten - 2009-11-13

    Real interesting. I wouldn't mind seeing such a thing in Trunk. How configurable is it?

    [+1] from me, from what I've read. Still need to see the source though.

     
  • karsten-thiemann

    Hi Tobi,

    sounds great, we use something similar (but hardcoded) on some tables. I would like to see it in trunk. So [+1] from me.

    Regards,
    Karsten

     
  • Mario Calderon

    Mario Calderon - 2009-11-13

    Hi Tobi,

    -another good idea by Metas-

    +1 fro me.

    Mario Calderon

     
  • Angelo Dabalà

    Angelo Dabalà - 2009-11-13

    Hi Tobi,

    sounds really useful

    +1 for me

    Angelo

     
  • Tobias Schöneberg

    Hi,
    I just added a patch that contains code and migration skript (only postgres has been tested so far). I hope you

    After applying there should be a new window "Relation Type" in that window you can define furter relations (by releation I mean a set of record pairs).
    I already added a relation type that finds orders for an invoice and vice versa as mentioned in the example.

    Other possible types include "Order<->Open Invoice" or "Invoice<->Credit Memo" (at least I think so ;) )

    It makes heavy used of AD_Reference. Note that the Window in AD_reference can is evaluated to decide on which window to open for the zoom target. If it is unset, the AD_Window_ID in the zoom target's table is used instead.

    Feel free to check it out and pls give us your feedback.

    Regards
    Tobi

     
  • Redhuan D. Oon

    Redhuan D. Oon - 2009-11-13

    +1 vote

     
  • Carlos Ruiz

    Carlos Ruiz - 2009-11-13

    Script for postgresql (tested with pg 8.3.8)

     
  • Carlos Ruiz

    Carlos Ruiz - 2009-11-13

    Hi Tobi,

    The idea is excellent and the implementation really good, but I think it's still incomplete.

    So, I vote -1 (will change my vote to +1 after discussion and completion).

    My peer review:

    1 - Attached file xxx_FR2897194_Adv_Zoom_for_postgresql.zip -> xxx_FR2897194_Adv_Zoom.sql

    2 - New zoom is "overwriting" the default option

    3 - New zoom options are not translated

    I better explain 2 and 3 with a GardenWorld example:

    Open "Sales Order" window, search the DocumentNo=80002 and push the "Zoom Across" button:

    Before the patch the button shows:
    Invoice (Customer) (#1)
    Shipment (Customer) (#1)
    both translated

    After the patch the button shows:
    Invoice (#1)
    not translated - and it doesn't show the link to Shipment, just to Invoice

    As Adempiere detects automatically the relations below the table, based on "foreign key" I think it will be better to preserve such functionality, and just replace those configured.

    I mean, the best would be to show in the order window:
    Invoice (Customer) (#1) -> taken from the new functionality
    Shipment (Customer) (#1) -> deducted from the old functionality
    both translated

    What I see is: Adempiere deducts the relations even for new custom tables created, with this functionality enabled, then the auto-deduction will be lost.
    So, my advice is to preserve the auto-deduction, and just replace those configured.

    Or - or - we can make it configurable, you could add a field to the table AD_RelationType to indicate if you want to "Overwrite" or "Replace" the zooms for the table.

    4 - About code, I find the code very readable and properly written.
    Please add GPL Header to all the new classes.

    5 - I think the best would be to implement same behavior in zkwebui (AbstractADWindowPanel + WZoomAcross)

    NOTE: We need to define if officially zkwebui is the official Adempiere web client to change this recommendation into a rule.

    Regards,

    Carlos Ruiz

     
  • Tobias Schöneberg

    Hi Carlos,
    thank you for the review.
    I'll fix the issues and come back with another patch.

    Best Regards
    Tobi

     
  • Tobias Schöneberg

    new patch fixes the issues found by carlos

     
  • Tobias Schöneberg

    hi all,
    I think I fixed everything Carlos mentioned.

    The "old" generic zoom targets are still deducted from the AD and presented to the user, Unless there is a target found by a relation type (the new funktionality) and that target has the same label. A label in this case can be the name of the zoom target window or the role as set in the rule.

    I also implemented the same behavior in zkwebui, but I didn't really got around to test it as we currently don't use the web client and it would take me a lot of time to roll out the changes to a test server. Could someone pls test it for me?

    Regards Tobi

     
  • Carlos Ruiz

    Carlos Ruiz - 2009-11-18
    • status: open --> open-remind
     
  • Carlos Ruiz

    Carlos Ruiz - 2009-11-18

    Thanks Tobi, I'm this week teaching a training, I'll take a look whenever I have some time.

    Regards,

    Carlos Ruiz

     
  • Carlos Ruiz

    Carlos Ruiz - 2010-03-19
     
  • Carlos Ruiz

    Carlos Ruiz - 2010-03-19

    Hi Tobi,

    Excellent work.

    I uploaded a patch applicable to the trunk as of today, file UPDATEDFR2897194.patch

    I tested in swing and zkwebui and both are working fine.

    I vote +1 to include this in trunk at this moment (sorry for the delay).

    Maybe as a last improvement you could consider one thing (not a condition to go trunk):

    1 - If possible, add by default on adempiere seed the new two duplicated windows to be discovered automatically from BP, and other windows relating to M_InOut. I mean the windows "Customer RMA" and "Vendor RMA".

    These windows are duplicates of "Material Receipt" and "Shipment (Customer)" - and I think it will be best to include also the relation type for these two windows as at this moment they're counted wrongly.

    I mean - for example, if you add a "POS Order" for Patio - and then approve an RMA for the shipment and fill/complete the Customer RMA - when pushed the zoom button the menu will show "Shipment (Customer) #2" when in reality there is just one shipment - and the other one is the Customer RMA.

    So, we have now 7 votes to go trunk - and one functional/technical peer review approving it.
    Let's integrate it! :-)

    Regards,

    Carlos Ruiz

     
  • Carlos Ruiz

    Carlos Ruiz - 2010-03-19
    • priority: 5 --> 3
    • milestone: --> Core
     
  • Carlos Ruiz

    Carlos Ruiz - 2010-03-20
    • assigned_to: nobody --> globalqss
     
  • Tobias Schöneberg

    Minor fix and new types

     
  • Tobias Schöneberg

    I created another patch (against rev 11753) with

    -a minor fix in ZoomInfoFactory to prevent double entries
    -some order<->inout<->invoice related types
    -two types BPartner<->Vendor_RMA and BPartner<->Customer_RMA

    Could anyone pls test those new types?
    Bty: I changed the naming convention for the AD_References used in relation types. I hope the are more ...even more ;) ... explaining that way.

    Regards
    Tobi

     
  • Tobias Schöneberg

    Btw, after application of the migrations skript, one still needs to add the "Relation Type" window to the "System Admin" Role.

     
  • Carlos Ruiz

    Carlos Ruiz - 2010-03-22

    Thanks Tobi,

    Committed revision 11773
    http://adempiere.svn.sourceforge.net/adempiere/?rev=11773&view=rev

    Fixed a problem with the GenericZoomProvider - now it's using the whereClause of the first tab.

    And fixed the relations - instead of M_RMA they are now pointing to M_InOut for return documents.

    Tested and it's working right.

    Regards,

    Carlos Ruiz

     
  • Mario Calderon

    Mario Calderon - 2010-03-26

    Hi Tobi, Carlos,
    we downloaded and tested this FR. I find it very useful for cases where the relation goes through various tables and writing reports is too complicated.

    After doing all possible mistakes, once you found the way, it is relatively easy to configure new relations.

    In lack of wiki page, I attach an example here for a case a customer asked us a while ago and here we we able to solve it elegantly testing this FR. The example :Provider Invoices <-> Provider Material Receipt.
    The relation goes over 5 tables.

    Thanks for this excellent feature!

    Best regards,
    Mario Calderon

     
  • Mario Calderon

    Mario Calderon - 2010-03-26

    Example Zoom Across

     
1 2 > >> (Page 1 of 2)

Log in to post a comment.