Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - ThorstenW

Pages: [1] 2 3
1
[...] Moreover, when I activated the debug mode, this MYSQL error was displayed: "Unknown column 'get_read_state_from_server' in 'field list'".

This is caused by the current upgrade procedure which requires two independent procedures to update the database. If you skip one, you are stuck with an inconsistent state of your installation.

Reason & Solution:
[Step1] The installation files (e.g. fengoffice_3.4.1.zip) contains the core files including three preinstalled plugins "core_dimensions", "mail", "workspaces".
[Step2] The main upgrade script (fengoffice/public/upgrade) only updates the core database tables without those of the preinstalled plugins.
If you stop here, your installation will most likely be broken, as the plugin files are updated but the database is not.
(in this case: 'get_read_state_from_server' is a new field introduced to the table 'mail_accounts' of the mail plugin. This table doesn't get updated by Step 2 so the mail plugin fails and breaks the installation)
[Step3] You can't use the GUI due to the error. Therefore you must run the plugin update script (php fengoffice/public/install/plugin-console.php update_all) from console/command line to complete the database update for the plugins.

HTH
Thorsten

2
Warning: OpenGoo 1.5 BETA 3 is not suitable for production environments. Download.
[...]
What has been improved:
  • Drag and drop now doesn’t require that you select rows before dragging, and an icon was added to make it easier to know where to drag a row.

Holds true only if you drag an unselected row using the second column (small dotted area).
Otherwise you get a "Success: 0 Object(s) moved successfully"

Another scenario:
You selected a row earlier, but now choose to drag&drop another one. The row that gets moved/copied is the selected one (might even be scrolled out of view ) and not the one that has actually been dragged.

But that's only finetuning. You are doing a great job!

Looking forward to the official release! :)
Thorsten

3
Update:

Tracked it down to the PK creation of the following Table:

Quote
CREATE TABLE IF NOT EXISTS `<?php echo $table_prefix ?>template_object_properties` (
`template_id` INT( 10 ) NOT NULL ,
`object_id` INT( 10 ) NOT NULL ,
`object_manager` varchar(255) NOT NULL,
`property` VARCHAR( 255 ) NOT NULL ,
`value` TEXT NOT NULL ,
PRIMARY KEY ( `template_id` , `object_id` ,`object_manager`, `property` )
) ENGINE=<?php echo $engine ?> <?php echo $default_charset ?>;

For now, I created the PK without "property" to get around the limit. (and being able to do further testing ;) )

//edit:
next minor issue:
MySQL said: Unknown column 'is_order_by_asc' in 'og_reports'
at least, quite obvious^^

the rest went through smoothly:
# Database schema transformations executed (total queries: 26)
# 1 public files migrated to upload directory.
# OpenGoo has been upgraded. You are now running OpenGoo 1.5-beta2 Enjoy!


Hope, this feedback is helpful,
Thorsten

4
Hi,

was about to upgrade my old test installation to the current beta.
Seems I'm lucky enough to encounter DB upgrade Problems every time ;)

Recent error:

Quote
# Database schema transformations executed (total queries: 5)
# OpenGoo has been upgraded. You are now running OpenGoo 1.4.2 Enjoy!
# Upgrade script has connected to the database.
# Test query has been executed. Its safe to proceed with database migration.
#
# Failed to execute DB schema transformations. MySQL said: Specified key was too long; max key length is 1000 bytes
# Error upgrading to version 1.5-beta2

I looked through the "figazza" script but didn't find anything suspicious.

Greetings,
Thorsten

5
Bitteschön :)

@"Arbeitsberich": Ich benutze die englische Oberfläche und liege dann beim Erraten der deutschen Formulierung gelegentlich daneben ;D

Grüße,
Thorsten

6
Sollten die Felder nicht auftauchen, hast Du sie nicht wie beschrieben im Administrationsbereich angelegt, sondern direkt in der Notiz ;)

7
Im Administrationsbereich lassen sich eigene Eigenschaften für Objekte ergänzen. Diese können dann auch in Reports genutzt werden.

Da solche Eigenschaften aber dann für ALLE Objekte der gleichen Art (in diesem Fall Notizen) gelten, sollte das Feld vielleicht allgemeiner gefasst werden.
Also statt einer Checkbox mit dem Namen "Guter Nutzer" Ja/Nein evtl ein Text-Feld "Typ", welches in diesem Fall dann zB "+" oder "-" enthält (welche dann im Report abgefragt werden können), bei Notizen in anderem Kontext dann aber nicht ganz unbrauchbar sind, sondern auch verwendet werden könnten.
Wobei eine Checkbox natürlich die bequemere Lösung wäre (kann man auch nicht aus Versehen was Falsches eingeben... )
Das müsst ihr einfach abwägen.

Grüße,
Thorsten

8
Hallo Stephan,

ich würde in dem Fall eine Notiz erstellen und mit dem Kontakt verknüpfen. Dort können dann alle die Infos hineineditieren und ihr habt gleichzeitig die Möglichkeit, dort Kommentare zu posten um ggf direkt zu dem Vorfall zu diskutieren.

Grüße,
Thorsten

9
Deutsch / Re: Fehler beim Abrufen von EMails
« on: July 05, 2009, 08:57:12 am »
meine Einstellung, die ich aus phpinfo() habe, sehen wie folgt aus:

upload_max_filesize   32M   32M
post_max_size           32M   32M

Ich denke, dass es daran nicht liegen kann .

Ich nehme an, der Wert  "memory_limit" steht bei Dir auf 96M, was dem Mail-Skript (welches für sich alleine gemäß der Fehlermeldung bereits 59M beanspruchen möchte) zusammen mit der "Grundauslastung" nicht auszureichen scheint.

Allerdings ist eine Einstellung von 96M bereits recht großzügig, sodass wohl in der Tat Bedarf besteht, hier eine Codeoptimierung der Entwickler anzustoßen.

Grüße,
Thorsten

10
Deutsch / Re: Import von Kontakte
« on: June 27, 2009, 07:20:15 pm »
evtl. wird die Ausführung des Skripts abgebrochen, wenn es zu lange dauert.

Entscheidend wäre hier die php-Einstellung max_execution_time.

11
Deutsch / Re: Maximale Dateigröße liegt bei 2MB zum hochladen!
« on: June 23, 2009, 04:21:55 pm »
Na dann Glückwunsch :D

12
Deutsch / Re: Maximale Dateigröße liegt bei 2MB zum hochladen!
« on: June 22, 2009, 02:23:47 pm »
Das in der PHP.INI zu ändern klingt für mich logischer als in der .htaccess Datei!

Ein wenig Literatur hierzu ;)
http://de.php.net/manual/en/apache.configuration.php
Quote
The behaviour of the Apache PHP module is affected by settings in php.ini. Configuration settings from php.ini may be overridden by php_flag settings in the server configuration file or local .htaccess files.

http://www.php.net/manual/en/configuration.changes.php
Quote
When using PHP as an Apache module, you can also change the configuration settings using directives in Apache configuration files (e.g. httpd.conf) and .htaccess files. You will need "AllowOverride Options" or "AllowOverride All" privileges to do so.

Wenn Dein Provider zurückschreibt, dass er das Limit selbst für Dich ändert, wird es mit den Berechtigungen für eigene Anpassungen wohl leider nicht weit her sein.

Neben den beiden bereits getesteten Möglichkeiten sehe ich keine weiteren Alternativen, die ohne direkten Serverzugriff funktionieren.
Man möge mich berichtigen, wenn ich hier falsch liege.

Grüße,
Thorsten

13
Deutsch / Re: Maximale Dateigröße liegt bei 2MB zum hochladen!
« on: June 17, 2009, 01:59:34 pm »
Hallo Frank,

die oben angegebenen Einträge stammen copy&paste aus der .htaccess, die ich für meine eigene Installation benutze. Das klappt einwandfrei (während Änderungen in der php.ini keine Auswirkungen haben).

Teste bitte, ob die .htaccess funktioniert, wenn Du nur eine Zeile (zB php_value memory_limit 32M) stehen lässt.

Wenn das der Fall ist, liegt es vermutlich daran, dass Du die Datei mit einem Editor bearbeitest, der die Zeilenumbrüche falsch setzt (In dem Fall zB notepad++ ausprobieren)
//edit: habe mal meine funktionierende Datei angehängt

Sollte der Fehler (ich nehme an Internal Server Error) weiter bestehen, ist Dein Apache-Server wohl zu restriktiv (kein AllowOverride All) konfiguriert.

Grüße,
Thorsten

14
Deutsch / Re: Maximale Dateigröße liegt bei 2MB zum hochladen!
« on: June 16, 2009, 02:17:56 pm »
Hallo Frank,

um zu testen, ob Du die Werte überhaupt ändern darfst, kannst Du die angehängte Datei auf Deinen Server laden und schauen, ob die Werte
upload_max_filesize
post_max_size
geändert werden.

Falls es klappt, könntest Du versuchen, die Werte in der .htaccess zu ändern, statt in der php.ini. Wenn sich oben bereits nichts ändert, sieht es jedoch schlecht aus.

Grüße,
Thorsten

//edit:
Kleine Ergänzung zum Obigen. Versuche auf jeden Fall, die Werte per .htaccess zu ändern, auch wenn der php-Test negativ ausgeht.
Sollte nämlich funktionieren.

Die Einträge sähen dann wie folgt aus:
php_value memory_limit 32M
php_value max_execution_time 600
php_value post_max_size 130M
php_value upload_max_filesize 128M
etc...

15
Deutsch / Re: Speicherort der hochgeladenen Dokumente
« on: June 16, 2009, 02:06:59 pm »
Hochgeladene Dateien werden im Ordner "uploads" abgelegt. Die "Ordnung" erfolgt allerdings mit Hilfe interner Schlüssel.

Deine hochgeladene Beispiel-Datei "readme.txt" würde dann etwa als
\opengoo\upload\1930d\4a9x4\83933\db3948sdf89cd38f42dd7628
gespeichert.

Auf den ersten Blick vielleicht unverständlich, aber schließlich ist der direkte Zugriff auf die Dateien ohne den Weg über OG (und die damit verbundene Berechtigungsprüfung) nicht gewünscht. Und Namenskollisionen gibt es so natürlich auch nicht.

Grüße,
Thorsten

Pages: [1] 2 3