On 2012-12-10, at 13:20 , Valentin LAB wrote: > BTW, it seems sequenceable list do not get a correct sequence at > creation (they all stay at 0), which seems to be a design choice that I > don't understand (this was already the case since... the beginning). I > may have missed something, but moving a line around re-sequence > correctly all lines... so I do not understand why this is not done also > at creation.
Because it doesn't really make sense to do it by default? What should the sequence number be for a creation "at top"? What if the object is being created on the second page? Or even created from the first page with a bunch of unseen record? Sequence numbers are not unique, and if you need a default it's easy enough to define default values in term of ir.sequence, postgres sequence or even just max() on the existing records. > Can you explain me the position of the cursor when using "arrow down", > or when is the whole content of a cell selected by default ? When done so automatically by your browser, which is why TAB does it within a record, that's just the default browser behavior. > When do we exit edition mode ? (down arrow and tab won't, left arrow at the > end of the cell will). [ESC], pressing the Discard link or Save button. In O2Ms, when moving the focus out of the editable list as well. > When is the content of the line saved ? (moving to another cell of the same > line seems to do so, as enter key…) Switching to a different row or pressing the [Save] button. In O2M, when moving the focus out of the row (and editable list). The data-loss bug when clicking on a different row was due to a synchronization error in the form fields due to the way browsers sequence their DOM events. (essentially form fields listen to the [change] DOM event to synchronize the stored value and the UI value, but [change] only fires after [blur], in many situations the editable listview programmatically triggers a form save without any [blur] occurring and the form failed to correctly synchronize the values to save) > Why do the down arrow move to the end of the cell content at first > press, then if at the end of the cell content it goes down ? Moving to cell end on [down] is your browser's normal behavior, [up] and [down] are only handled by the editable listview when the cursor is at the end of the cell both to allow this behavior and (mostly) so that textareas (multiline text fields) can be used at all. > The new line created doesn't disappear when empty, and disappear in some > cases (o2m widget, alt-tab out of browser) when filled ! o2ms attempt to save-on-blur (keeping 6.1 behavior), which might also be the source for the alt-tab disappearance. It is possible that the previous form bug made the listview believe no data had been entered in the row, and thus discards the row on blur (rather than save it), in that case it should now be fixed. _______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-framework Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
