Menu
▾
▴
#2145 Wrong behavior of non-automatic commit
Tools -> Preference -> Disable Automatic Commit checkbox
Relogin
Open Unit of Measure window
Create a NEW record - fill with any values the UOMCode and Name. Don't save.
1 - try to navigate to a different record using next/previous button
CORRECT -> a window appears asking if the user wants to save - if user answers No then the edited record is kept in screen
2 - try to navigate to a different tab (i.e. Conversion) pushing in the tab, or the "Detail record" button
CORRECT -> a window appears asking if the user wants to save.
WRONG -> if user answers No then the edited record is lost
3 - Navigate to the FIRST record in UOM (it must be 6PK)
change any value (i.e. change description) - don't save
navigate to the next record
WRONG -> the record is saved without asking user
This wrong behavior is present in any window on the first record
Regards,
Carlos Ruiz
Hi Carlos
Yap it is a potential bug and i am working to fix it out.
Hi Carlos
while creating the new record when we will select the next or prev ... button and system ask for data save and if we will select no then system should not return with the save record, it should move to the concern record (like next or previous etc) without saving the current.
What do you say?
Reg
VOSSCOM
Hi Vosscom,
> while creating the new record when we will select the next or prev ...
> button and system ask for data save and if we will select no then system
> should not return with the save record, it should move to the concern
> record (like next or previous etc) without saving the current.
Yes, I think that's a correct behavior. User is answering that he doesn't want to save the record, so IMHO it implies he wants to move to the next/prev record.
Regards,
Carlos Ruiz
Hi Carlos
we have done till this issue and now resolving the 2nd issue (Mentioned above).
As some students are still working on the 1st issue so will share the solution with the community in a few days.
Regards
VOSS Com (Virtual University Open Source Software Community)
Lahore Pakistan.
hi Carlos
we have uploaded the patch of the 2nd bug mentioned above. Following is the link of the patch:
http://sourceforge.net/tracker/index.php?func=detail&aid=2898373&group_id=176962&atid=879334
Hi carlos
Following is the solution of the 1st bug mentioned above:
if ((newRow > m_currentRow) && (m_mTable.getNewRow()!=-1))
newRow--;
dataIgnore();
it should be pasted inside "if (m_mTable.dataSave(newRow, false) == false)"
of
"int org.compiere.model.GridTab.navigate(int targetRow)"
method.
Following is getNewRow() getter which should be included in the GridTable class:
public int getNewRow(){return m_newRow;}
Waiting for comments:
Regards,
VOSS Com
hi Carlos
Solution of 3rd bug:
In dataSave (boolean manualCmd) function of GridTable class we are passing ' 0' as old value in the following method call:
m_vetoableChangeSupport.fireVetoableChange(PROPERTY, 0, m_rowChanged);
we have hard coded the 2nd argument to '0' and the value of m_rowChanged is '0' as well in case of 1st record of each tab of each window, so that's why it save the modification without asking, if we modify '0' to -1 then our issue will be resolved.
waiting for your response.
Regards
VOSS Com
Thanks a lot VOSS Com!
Solved the test case [3]
Committed revision 11162.
http://adempiere.svn.sourceforge.net/adempiere/?rev=11162&view=rev
Regards,
Carlos Ruiz
Sorry, commit 11162 was to fix test case [1] - test case [3] still open ....
Thanks a lot VOSS Com!
> we have hard coded the 2nd argument to '0' and the value of m_rowChanged
> is '0' as well in case of 1st record of each tab of each window, so that's
> why it save the modification without asking, if we modify '0' to -1 then
> our issue will be resolved.
You were totally right - I changed it and worked.
Committed your solution with revision 11163
http://adempiere.svn.sourceforge.net/adempiere/?rev=11163&view=rev
Regards,
Carlos Ruiz
Committed revision 11164.
http://adempiere.svn.sourceforge.net/adempiere/?rev=11164&view=rev
To make zk behave samely as swing.
Regards,
Carlos Ruiz
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).