Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
0015138Openbravo ERPA. Platformpublic2010-11-09 10:282011-01-18 00:00
egoitz 
egoitz 
urgentminoralways
closedsuspended 
5
2.50MP23 
2.50MP26 
Core
No
0015138: If you create new tabs on the settlement window and you deactive the standard ones the links to settlement window don't work
If you create new tabs on the settlement window and you deactive the standard ones the links to settlement window don't work.

If you want to add more fields on the c_settlement_cance and c_settlement_generate tabs, on c_settlement window, you have to create new views and tabs, because
views of core can not me modified.
After create the new tabs you will need to deactivate the standard tabs and show only the new tabs created for the new views.


After apply this changes and rebuild, you get an error when navigating from c_bankstatement lines to the payment.
This happens because on the referencelink.java file the tableid of the standard view is hardcoded.

            strTableReferenceId = "800021";
-Create a new module, with prefix, and datapackege, and set it as indevelopment.
-Create two new views copying them from the following:
'C_Debt_Payment_Generate'
'C_Debt_Payment_Cancel'
-Define the views on the application dictionary as new tables.
-Create two new tabs for this views on the settlement window.
-Deactivate the two subtabs for tables
'C_Debt_Payment_Generate'
'C_Debt_Payment_Cancel'
on the settlement window
-Compile the application.
-REstart tomcat
-Go to bankstatement window and select one bankstatemnte
-Go to the lines
-Try to navigate using the payment link
*You get an error:

Window not found: 800005

No tags attached.
related to feature request 0015379 closed gorkaion Extend navigation model 
related to defect 00157232.50MP27 closed alostale the link to project window can not be changed 
Issue History
2010-11-09 10:28egoitzNew Issue
2010-11-09 10:28egoitzAssigned To => alostale
2010-11-09 10:28egoitzIssue Monitored: networkb
2010-11-22 08:35alostaleStatusnew => scheduled
2010-12-09 08:42alostaleRelationship addedrelated to 0015379
2010-12-09 08:42alostaleNote Added: 0033076
2010-12-09 08:54alostaleNote Added: 0033077
2010-12-09 08:54alostaleAssigned Toalostale => egoitz
2010-12-09 08:54alostaleStatusscheduled => feedback
2010-12-20 13:33egoitzPriorityurgent => high
2010-12-20 13:33egoitzTarget Version2.50MP25 => 2.50MP26
2010-12-20 13:34adrianromeroPriorityhigh => urgent
2010-12-20 13:34adrianromeroSeveritymajor => minor
2011-01-17 13:58adrianromeroNote Added: 0033684
2011-01-17 13:58adrianromeroStatusfeedback => closed
2011-01-17 13:58adrianromeroResolutionopen => suspended
2011-01-18 00:00anonymoussf_bug_id0 => 3160338
2011-02-09 11:52alostaleRelationship addedrelated to 0015723

Notes
(0033076)
alostale   
2010-12-09 08:42   
A complete solution for this issue will be implemented in 3.0 (0015379)
(0033077)
alostale   
2010-12-09 08:54   
Should this issue be fixed in 2.50 with a specific workaround for this concrete case, or just wait for 3.0 complete implementation?
(0033684)
adrianromero   
2011-01-17 13:58   
This issue will be addressed in the 3 version