Merge lp://staging/~hirt/ocb-addons/6.1_stock_use_date_always into lp://staging/ocb-addons/6.1

Could you explain #93?

And date and date_expected are different things in my opinion. So we lose data the way you propose.

Actually, I don't even exactly understand the problem you want to fix here. Please file a bug report and elaborate there.

Dear Holger,

Thanks for your analysis and your patience.

I finally added a bug report (Bug #1265608) for explaining the sorting problem with the date_expected vs. date.

Please have a look at the Bug #1265640 for explanation of #93

Dear Etienne,

I do not think it is a good idea to have one merge proposal for two changes that are nearly totally unrelated. Except for the fact that they modify the same file. Please put the change of the address selection in a separate proposal.

As for the ordering problem, I think your proposal is quite risky. If you really want to be sure that date is always filled with a valid value - based on date_expected until a move is done -, I feel it would be more appropiate to override create/write methods. Otherwise you might still end up sorting on an date withouth value.

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?