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
Hi Tobias,
sounds very good!
[1+] to integrate it in trunk.
Regards,
Trifon
www.catura.de
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.
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
Hi Tobi,
-another good idea by Metas-
+1 fro me.
Mario Calderon
Hi Tobi,
sounds really useful
+1 for me
Angelo
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
+1 vote
Script for postgresql (tested with pg 8.3.8)
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
Hi Carlos,
thank you for the review.
I'll fix the issues and come back with another patch.
Best Regards
Tobi
new patch fixes the issues found by carlos
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
Thanks Tobi, I'm this week teaching a training, I'll take a look whenever I have some time.
Regards,
Carlos Ruiz
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
Committed revision 11753.
http://adempiere.svn.sourceforge.net/adempiere/?rev=11753&view=rev
Regards,
Carlos Ruiz
Minor fix and new types
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
Btw, after application of the migrations skript, one still needs to add the "Relation Type" window to the "System Admin" Role.
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
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
Example Zoom Across