Trunk: Inkonsistenz bei Bestellstatus "Storniert"

[Torsten Riemer]

Die Stornierungsmöglichkeit im Trunk ist derzeit inkonsistent umgesetzt. In der "/_installer/modified_utf8.sql" heisst es:

INSERT INTO orders_status VALUES (0,1,'Cancelled');
INSERT INTO orders_status VALUES (0,2,'Storniert');
INSERT INTO orders_status VALUES (1,1,'Pending');
INSERT INTO orders_status VALUES (1,2,'Offen');
INSERT INTO orders_status VALUES (2,1,'Processing');
INSERT INTO orders_status VALUES (2,2,'In Bearbeitung');
INSERT INTO orders_status VALUES (3,1,'Delivered');
INSERT INTO orders_status VALUES (3,2,'Versendet');

In der "/_installer/modified_utf8.sql" führen wir jedoch folgenden SQL-Befehl aus:

#Tomcraft - 2011-03-02 - Added status for cancelled orders
#(Set next available number for status ID in both languages)
INSERT INTO orders_status (orders_status_id, language_id, orders_status_name)
  SELECT MAX(orders_status_id)+1, 1, 'Cancelled' FROM orders_status;
INSERT INTO orders_status (orders_status_id, language_id, orders_status_name)
  SELECT MAX(orders_status_id)+1, 2, 'Storniert' FROM orders_status;

[Simon Heinrich]

Der untere Teil aus update_1.0.7.0_to_2.0.0.0.sql berücksichtigt die Möglichkeit, dass ältere Shopversionen vielleicht schon mit anderen Status durch den Shopowner ausgestattet wurden.
Da es die ID 0 in der Regel nicht gibt, kann das auch mit der Methode in der modified_utf8.sql durchgeführt werden.

Zukünftige Status sollten aber mit +1 hochgezählt werden (wie es im moment noch der Fall ist) ...

[Torsten Riemer]

Die Unterschiede sind mir schon klar, aber wir sollten uns hier für eine konsistente Lösung entscheiden und die dann konsequent umsetzen.

[Simon Heinrich]

Fixed @r5780

[Torsten Riemer]

Danke dir, aber wir sollten das Ticket hier ruhig noch offen halten, damit wir auf dem Schirm haben die Vorgehensweise bei Stornierungen nochmal zu überdenken. ID 0 ist da wohl nicht die beste Option.

[Torsten Riemer]

In Shopversion 2.00

[Torsten Riemer]

In 7489:

Fix #121