[14.0][IMP] shopfloor_delivery_shipment: add sales grouping

[TDu]

[OCA-git-bot]

Hi @sebalix, some modules you are maintaining are being modified, check this out!

[TDu]

About doing grouping and sorting server side vs client side. To me the less client side code we have the better. The data is being parsed in the backend anyway so if it needs some default grouping sorting why not doing it then ?

For this special case, we could add a field in the package level data to store the sales information. But then half of the problem would be fixed because we want to also have a sorting as well on which sales order has been started to be processed or not.

[mmequignon]

the less client side code we have the better

Agreed.

[simahawk]

To me the less client side code we have the better.

Very bold statement :smile: And what is the rationale for this? Personal taste only? :)

The point is that this is not consistent with what has been done in the past. This is really something only related to the way you display info on the screen. Not on how data has to be handled server side.

Now, I understand you can be annoyed if someone ask you to refactor what you have done server side / client side.... yet, from my POV is not a good idea to break this design decision. Especially w/o proper motivation if not "I like it more server side". Not to mention that this is adding more not needed complexity server side, whereas the only change that would be needed is to add the sale order ref.

[TDu]

To me the less client side code we have the better.

Very bold statement 😄 And what is the rationale for this? Personal taste only? :)

The point is that this is not consistent with what has been done in the past. This is really something only related to the way you display info on the screen. Not on how data has to be handled server side.

Now, I understand you can be annoyed if someone ask you to refactor what you have done server side / client side.... yet, from my POV is not a good idea to break this design decision. Especially w/o proper motivation if not "I like it more server side". Not to mention that this is adding more not needed complexity server side, whereas the only change that would be needed is to add the sale order ref.

I am not sure what in my answer made you think that I was annoyed by your comment ? I don't see any feeling being shown in there.

Now about my comment

the less front end code the better.

My thoughts about this is (in relation to this specific project) that the backend code is well tested compared to the front end and defacto much easier to maintain in the long run. Also your mention of not breaking some design decision without clearly stating what those decisions are is not very helpful.

Anyway for this specific case adding a key (sales.order) within the package levels would not completely resolve the issue because the intend as specified in my previous comment

For this special case, we could add a field in the package level data to store the sales information. But then half of the problem would be fixed because we want to also have a sorting as well on which sales order has been started to be processed or not.

The part not solved, would be sorting the sales order that have already been started before the one the user has not yet started to load. Of course it could be done with some added key in the sales order, but I am afraid that would beak another design rule.

[simahawk]

I am not sure what in my answer made you think that I was annoyed by your comment ? I don't see any feeling being shown in there.

Why annoyed? "bold" does not mean that you are annoyed... I was just fooling you because you were not bringing any strong technical motivation to back your statement. No feelings involved :wink: :hugs: However, for my personal improvement, let me know if this way of saying might imply other meanings :pray:

Now about my comment

the less front end code the better.

My thoughts about this is (in relation to this specific project) that the backend code is well tested compared to the front end and defacto much easier to maintain in the long run. Also your mention of not breaking some design decision without clearly stating what those decisions are is not very helpful.

Well, I'm not sure it is written somewhere (I can check that) but I can tell you that when we 1st designed this stack both me and Guewen agreed on leaving such tasks to the front (presenting things vs gathering data). And you can see this everywhere in the code (as far as possible). Regarding test coverage: that's not a good reason. If that's a problem, we have to address that, instead of working around it.

Anyway for this specific case adding a key (sales.order) within the package levels would not completely resolve the issue because the intend as specified in my previous comment

For this special case, we could add a field in the package level data to store the sales information. But then half of the problem would be fixed because we want to also have a sorting as well on which sales order has been started to be processed or not.

The part not solved, would be sorting the sales order that have already been started before the one the user has not yet started to load. Of course it could be done with some added key in the sales order, but I am afraid that would beak another design rule.

You can sort AND group client side. Why do you think this is not feasible/desirable?

[github-actions[bot]]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.