Jan Büren [Wed, 30 Nov 2011 12:57:03 +0000 (13:57 +0100)]
Die Variable $readonly in display_row wird niemals ausgelesen.
S.a. Anmerkung von Sven:
...und hier wird es nur gesetzt, aber nicht konsumiert. Seit den strict Änderungen wird auch keine Variable mehr indirekt aufgerufen (a la $name = 'readobly'; print
$$name), und wird auch nicht implizit an html oder print Templates weitergeleitet.
git blame sagt zu io.pl:127:
Lieferscheine im Einkauf und Verkauf. Bisher nur gemerget, noch nicht getestet.
...der Commit ist berüchtigt, weil Mosu da nur die Aufträge copy&pasted hat, und tabellen und bezeichner geändert hat. In dem Commit sind ein paar tote Codestellen reingekommen.
Jan Büren [Wed, 30 Nov 2011 11:27:54 +0000 (12:27 +0100)]
Programmlogik für Recht 'Schreibgeschützte Preise' (s.a. Commit davor)
Details: Vergessen bei dem Commit von gerade, die entsprechenden Programmänderungen auch zu committen, betrifft: Übersetzungen, Recht in Auth.pm sowie die entsprechende neue Logik in io.pl->display_row
Jan Büren [Wed, 30 Nov 2011 11:18:14 +0000 (12:18 +0100)]
Neues Recht 'Schreibgeschützte Preise' hinzugefügt und als Standard aktiviert gesetzt.
Zusätzliches Recht edit_prices für das cgi->textfield Attribut readonly bei Preisen und Rabatten hinzugefügt.
Das Upgrade-Skript hakt standardmässig dieses Recht an, sodass es keinen Unterschied zu vorhergehenden Version gibt (analog zu auth_enable_sales_all_edit.pl).
Sven Schöling [Tue, 22 Nov 2011 13:07:56 +0000 (14:07 +0100)]
User Attribut "role" entfernt.
Wurde früher benutzt um Rechteverwaltung zu emulieren. Es gab noch zwei
Instanzen wo das benutzt wurde um zu kontrollieren ob das Feld bcc angezeigt
werden soll, die sind jetzt auf das Recht "email_bcc" gemappt.
Als Schmankerl: role wurde im Userbereich unter den Benutzereinstellungen als
hidden mitgeschleift und konnte von jedem Benutzer selbst gesetzt werden.
Sven Schöling [Tue, 22 Nov 2011 11:08:21 +0000 (12:08 +0100)]
rp.pl::report auf template umgestellt.
Bei der Umstellung sind die folgenden vier Funktionalitäten aufgefallen:
- tax_collected
- tax_apid
- nontaxable_purchases
- nontaxable_sales
Diese 4 Funktionen waren schon in der ältesten erhaltenen git Version von
Lx-Office deaktiviert, und laut Moritz nur für den amerikanischen Markt
brauchbar. Ich habe die Grundfunktionalität erhalten, und die HTML Blöcke
mitportiert, aber unkonditional deaktiviert. Ausserdem werden die dispatching
Variablen nicht an das Template weitergereicht.
Im gleichen Zuge ist die Funktion RP->get_taxaccounts aufgefallen. Die wird
anscheinend nur von den oben genannten benutzt und enthält seit 2007 einen
Typo, der sie nutzlos macht (ISE beim Aufruf). Da das nie aufgefallen ist, wird
sie wohl nicht anderweitig benutzt. Ich entferne sie nicht in diesem Commit,
weil es nichts mit der template Umstellung zu tun hat.
Moritz Bunkus [Wed, 9 Nov 2011 09:35:03 +0000 (10:35 +0100)]
Anlegen der Auth-DB fixen
Auth.pms Session-Management kam nicht damit zurecht, wenn die Auth-DB
bzw. das "auth"-Schema darin noch nicht existiert haben. Das passiert
z.B., wenn die Auth-DB gerade über den Admin-Bereich angelegt werden
soll.
G. Richardson [Mon, 31 Oct 2011 15:24:41 +0000 (16:24 +0100)]
Offene Posten nach Rechnungsnummer suchen
* wenn es mehrere Rechnungen gab, wo Rechnungsnummer übereinstimmt (LIKE),
wurde die erste Rechnung aus den Ergebnissen verwendet
-> jetzt wird erst alle Rechnungen durchgegangen ob es eine genaue
Übereinstimmung gibt und dann die genommen, ansonsten wieder die Erste
* nach Ermittlung der Rechnung wurde anhand des Kundennamens und nicht anhand
der Kunden-ID nach Kunden gesucht, was schlecht ist wenn es viele Kunden mit
identischem Namen gibt
-> sofern die customer_id ermittelt wurde wird jetzt der Kunde anhand der ID
rausgesucht
G. Richardson [Mon, 31 Oct 2011 15:24:41 +0000 (16:24 +0100)]
Offene Posten nach Rechnungsnummer suchen
* wenn es mehrere Rechnungen gab, wo Rechnungsnummer übereinstimmt (LIKE),
wurde die erste Rechnung aus den Ergebnissen verwendet
-> jetzt wird erst alle Rechnungen durchgegangen ob es eine genaue
Übereinstimmung gibt und dann die genommen, ansonsten wieder die Erste
* nach Ermittlung der Rechnung wurde anhand des Kundennamens und nicht anhand
der Kunden-ID nach Kunden gesucht, was schlecht ist wenn es viele Kunden mit
identischem Namen gibt
-> sofern die customer_id ermittelt wurde wird jetzt der Kunde anhand der ID
rausgesucht
Moritz Bunkus [Wed, 2 Nov 2011 15:34:05 +0000 (16:34 +0100)]
Exceptions beim Speicher/Löschen von SL::DB-Objekten hochbubblen lassen
Die R::DB::O::transaction()-Funktion clobbert Exceptions
irgendwie. Deshalb diese erneut werfen, sofern sie beim Speichern
auftreten, und nicht nur einen Fehler zurückliefern.
Jan Büren [Thu, 27 Oct 2011 12:16:43 +0000 (14:16 +0200)]
> sobald ich jetzt eine neue Ware oder Erzeugnis anlege, und dann bei
> Bericht Kunde anhake, bekomme ich folgende Fehlermeldung:
>
> Can't call method "name" on an undefined value at SL/CVar.pm line 574.
Ahjo, hab den Fehler. Tausch mal bitte die Zeile 578 durch diese hier aus:
Jan Büren [Mon, 17 Oct 2011 11:40:03 +0000 (13:40 +0200)]
Stammdaten -> Berichte -> Kunden mit Kundentyp.
Die anschließende Sortierung nach Kundentyp liefert eine Fehlermeldung, da ein 'order by lower(business)' eine SQL-Fehlermeldung wirft (ct.business_id AS business).
Entsprechend die Abfrage erweitert, sodass ein 'order by business' analog wie bei quonumber etc passiert.
projects / kivitendo-erp.git / log