I can see that the 'date' usage is a bit of a mess: a halfhearted way of keeping it synchronized with date_expected is implemented using an on_change method, but there a places where a stock move is created without a value for 'date'. Note that your fix does not solve this either, because you only override the write() method. Biggest problem with this is that it messes up the sorting for existing moves if they don't have a 'date' set (I think that is what Ronald hints at above). In that case it seems better to me to be able to sort by expected date, even for delivered moves. Note that in 7.0, the 'date' field is hidden in the stock move tree views (group_no_one), so that a forward port of this fix would lead to seemingly slightly random orders in the views.
Maybe it is better to identify the places where 'date_expected' is written and 'date' is not kept synchronous. Fix this code. You can then as a user in 6.1 at least click on the 'date' column to see the moves ordered by this field (show the field in a custom module in 7.0), and maybe change the default order in a custom module (in 6.1 and 7.0).
You could also propose the changed order to trunk, see what they say. The gaps in the data could be filled in by a small query in the migration procedure.
I can see that the 'date' usage is a bit of a mess: a halfhearted way of keeping it synchronized with date_expected is implemented using an on_change method, but there a places where a stock move is created without a value for 'date'. Note that your fix does not solve this either, because you only override the write() method. Biggest problem with this is that it messes up the sorting for existing moves if they don't have a 'date' set (I think that is what Ronald hints at above). In that case it seems better to me to be able to sort by expected date, even for delivered moves. Note that in 7.0, the 'date' field is hidden in the stock move tree views (group_no_one), so that a forward port of this fix would lead to seemingly slightly random orders in the views.
Maybe it is better to identify the places where 'date_expected' is written and 'date' is not kept synchronous. Fix this code. You can then as a user in 6.1 at least click on the 'date' column to see the moves ordered by this field (show the field in a custom module in 7.0), and maybe change the default order in a custom module (in 6.1 and 7.0).
You could also propose the changed order to trunk, see what they say. The gaps in the data could be filled in by a small query in the migration procedure.
What do you think?