Projekt

Allgemein

Profil

« Zurück | Weiter » 

Revision ec4af566

Von Sven Schöling vor fast 2 Jahren hinzugefügt

  • ID ec4af5669ce6a05fb3da11f5b02f2580e4d92390
  • Vorgänger 467efa09
  • Nachfolger b03da1a4

TODO verschoben in das POD von SL::Model::Record

Unterschiede anzeigen:

SL/Model/Record.pm
None yet. :)
=head1 FURTHER WORK
=over 4
=item *
Handling of price sources and prices in controllers
=item *
Handling of shippedqty calculations in controllers
=item *
Autovivification of unparsed cvar configs is still in parsing code
=item *
Handling of changed customer/vendor
=item *
sellprice changed handling
=back
The traits currently encoded in the type data classes should also be extended to cover:
=over 4
=item *
PeriodicInvoices
=item *
Exchangerates
=item *
Payments for invoices
=back
In later stages the following things should be implemented:
=over 4
=item *
For SL::DB::Order and SL::DB::Reclamations the subtype should be saved in the database and not inferred from customer/vendor.
=item *
Further encapsulate the linking logic for creating linked records.
=item *
Better tests for auto-close of quotations and auto-delivered of delivery orders on save. Best to move those into post-save hooks as well.
=item *
More tests of workflow related conversions from frontend (current tests are mostly at the SL::Model::Record boundary).
=item *
More tests for error handling in controllers. I.e. if the given recordnumber is kept.
=back
=head1 AUTHORS
Bernd Bleßmann E<lt>bernd@kivitendo-premium.deE<gt>
doc/controller-refactor-todo.txt
nimmt:
- geparstes record objekt
-
rückgabe:
- record objekt, recalc fertig
save transaction:
phone note handling
custom shipto handling
item_ids_to_delete
order version
linked records
set_project_in_linked_requirement_specs
zu migrieren:
price source + price setzen
shippedqty calc
cvar config unparsed autovifify
history handling
setup_order_from_customer_vendor
sellprice changed
update_item_input_row (wenn picked)
evtl zu migrieren:
new_from_multi (in gleichem type)
new_from_multi (aus anderem typ z.B. do zu invoice)
nicht hierher:
- store_doc_to_webdav*
- close_quotations (management endpunkt)
neue typdaten:
- braucht der typ trasportkostenartikel
- workflow ziele (von hier zu x)
trait listen:
- hat price tax calculation
- hat lager (transfer_stock + undo_transfer_stock)
- hat subversion
- hat periodic invoices
- exchangerate
- close_quotations?
- payments (nur für rechnungen)
- DONE: new -> update_after_new: (aus add) neues record mit vorbereitenden sachen wie transdate/reqdate
- DONE: new_from_workflow: (aus add_from_*) workflow umwandlung von bestehenden records
- DONE: new_from_multi
- DONE: increment_subversion
- DONE: delete
- DONE: save mit voller vor/nach behandlung und transaction
- DONE: clone_for_save_as_new (für save_as_new)
======== second run ========
- DONE: S:M:R->delete/save bzw. _save_history: type data: snumber für history
- DONE: S:M:R->delete: kein croak sondern die, wenn transaction einen Fehler wirft
- S:M:R->new_from_workflow: type data: subtype_to_type
- DONE: S:M:R->new_from_workflow: no_linked_records als opt. flag
- DONE: S:M:R->increment_subversion: als trait bzw. type data: wer kann das überhaupt
- WIP: S:M:R->save implementieren
Allgemein:
- Geoffrey: Typos suchen
WIP: S:M:R: alle inline Kommentare prüfen, übersetzen und ins POD verlagen
Bugs:
- DONE: S:M:R->delete: snumbers in history ist leer
======== third run ========
- genaueren Typ (type data) irgendwie im Objekt/db speichern für Order und Reclamation (wie bei DeliveryOrder)
- S:C:Order/DeliveryOrder/Reclamation: Records verlinken: Vorbereitung im Objekt in make_order/reclamation verschieben?
======== fourth run ========
- prüfen, ob Angebote/Aufträge/Lieferscheine richtig auf geschlossen/geliefert gesetzt werden nach Workflows
- Typen in Objekten selbst speichern, nicht über customer/vendor id holen
======== an der Oberfläche testen, testen, testen ... ========
- DONE: bleiben item_ids der linked records/items beim Sortieren erhalten?
- WIP: Umwandeln Beleg/Beleg new_from / convert gegen linked records/items testen
- Umwandeln im front-end / Workflows gegen linked records/items testen
- Fehlerzustände in Controllern provozieren und prüfen, ob z.B. autom. vergebene Belegnummer erhalten bleibt

Auch abrufbar als: Unified diff