Mantis 1.2.11 Status nicht änderbar

[docbt]

Nein, der Befehl in der Konsole lief Problemlos durch.

Erst beim Aufruf des Install Scribtes mantisbt/admin/install.php

Meldet mir die Weboberfläche table already exist, erst nach dem Löschen der Tabellen klappte der Zugriff

Folgende Tabellen musste ich löschen damit ich Mantis lauffähig bekomme:

* mantis_plugin_table
* mantis_category_table
* mantis_bug_revision_table

[atrol]

Beim Vergleich der 1.2.10 und der 1.2.11 Version habe ich noch einen unterschiedlichen Eintrag in der bug_update_advanced_page.php gesehen,
davon habe ich auch noch einen Screenshot gemacht.

Die Änderungen stammen von diesem Fall http://www.mantisbt.org/bugs/view.php?id=14156
Das sind die darin durchgeführten Änderungen https://github.com/mantisbt/mantisbt/co ... 4fd3884b0e
Die Änderung im Verhalten zwischen 1.2.10 und 1.2.11 ist wohl darauf zurückzuführen.

Mir ist es nicht gelungen das beschriebene Verhalten zu reproduzieren.
Deshalb nochmal die Frage: Kann das Verhalten mit Mantis2Go reproduziert werden.
Den Einwand gegegen das Tool verstehe ich nicht.

Mantis2Go kommt durch nicht gesicherte Verbindung, nicht zum Einsatz.

Es geht lediglich darum, in einer lokalen Windows-Umgebung mit einem frisch aufgesetzten MantisBT 1.2.11 (nichts anderes ist Mantis2Go 1.0.7) das Problem Schritt für Schritt nachzuvollziehen.
Wenn klare Anweisungen vorliegen, wie das Problem in dieser Umegbung von Grund auf reproduziert werden kann, ist es meistens überschaubar einen Fehler zu finden.

erst nach dem Löschen der Tabellen klappte der Zugriff
Folgende Tabellen musste ich löschen damit ich Mantis lauffähig bekomme:

* mantis_plugin_table
* mantis_category_table
* mantis_bug_revision_table

Waren die Tabellen leer bevor sie gelöscht wurden?

Welcher Wert steht in der Tabelle "mantis_config_table" in der Zeile "database_version" in der Spalte "value" bevor das admin/install.php Script gestartet wird?

[docbt]

Kann das Verhalten mit Mantis2Go reproduziert werden.

Ich habe nun auch Mantis2Go installiert und dort die Datenbank eingefügt. Mit dem gleichen Ergebnis

Waren die Tabellen leer bevor sie gelöscht wurden?

Zum Teil.

* mantis_plugin_table - leer
* mantis_category_table - beinhaltet Daten
* mantis_bug_revision_table - leer

Welcher Wert steht in der Tabelle "mantis_config_table" in der Zeile "database_version" in der Spalte "value" bevor das admin/install.php Script gestartet wird?

In der Spalte "value" steht 63

Diese Meldung bekomme ich sobald ich die Datenbank importiert habe und das Script noch nicht durchlaufen lassen habe siehe Bild: mantis-import-table01.jpg

Beim durchlaufen des Scripts erhalte ich dann die Fehlermeldung, siehe Bild: mantis-import-table02.jpg

[atrol]

Ich habe nun auch Mantis2Go installiert und dort die Datenbank eingefügt. Mit dem gleichen Ergebnis

Zumindest ist damit ausgeschlossen, dass die Probleme nicht auf Betriebssystem, Datenbank, Websever oder HPP -Version zurückzuführen sind.
Das ist allerdings nicht das, was ich damit eigentlich bezwecken wollte.
Die Frage ist, ob das Problem mit einem frisch installierten Mantis2Go ohne darin enthaltene Daten von Grund auf nachzuvollziehen ist.
Falls ja, könnte ich das Problem in aller Ruhe lokal analysieren, ohne weiteres langwieriges Frage- Antwort Spiel.

[docbt]

Die Frage ist, ob das Problem mit einem frisch installierten Mantis2Go ohne darin enthaltene Daten von Grund auf nachzuvollziehen ist.
Falls ja, könnte ich das Problem in aller Ruhe lokal analysieren, ohne weiteres langwieriges Frage- Antwort Spiel.

Ja, ich hatte Mantis2Go für diesen Versuchszweck installiert. Und beim direkten Import der DB aus der Version 1.1.8 die Fehlermeldung (siehe unten) bekommen. Gibt es eine Möglichkeit den Import über einen Konsolenbefehl zu steuern? mysql -root -p bugtracker < bugtracker.sql ?

Der Import der DB von Mantis 1.1.8 > Mantis 1.2.10 ( Ubuntu, mit Löschen der 3 Tabellen ) und anschießenden Import auf > Mantis2Go 1.2.11 klappt ohne Probleme, jedoch ohne die Möglichkeit den Status zu ändern. Die Änderung in den Strukturen wird in den Tabellen weiter gegeben.

Meine Überlegung wäre, wenn man seit der Version 1.1.8 die DB in den nachfolgenden importiert ändern sich ja die Tabellen mit den Versionen. Aber mit dem Export der DB von Version 1.2.10 und dem Import in Mantis 1.2.11 verschwindet jedesmal die Auswahl zum Ändern des Status.

[atrol]

Sorry, entweder wir machen das so, wie ich mir das vorgestellt habe, was mir am liebsten wäre.

Das ist allerdings nicht das, was ich damit eigentlich bezwecken wollte.
Die Frage ist, ob das Problem mit einem frisch installierten Mantis2Go ohne darin enthaltene Daten von Grund auf nachzuvollziehen ist.
Falls ja, könnte ich das Problem in aller Ruhe lokal analysieren, ohne weiteres langwieriges Frage- Antwort Spiel.

Oder ich brauchde den Dump und die Konfigurationsdateien von 1.1.8
Versprechen will und kann ich aber nichts, ich kann nur begrenzt Zeit in dieses Thema investieren.

[docbt]

Also das Dump ist größer als 1,2 GB.

Die Frage ist, ob das Problem mit einem frisch installierten Mantis2Go ohne darin enthaltene Daten von Grund auf nachzuvollziehen ist.

Ich bin mir nicht sicher ob ich dich richtig verstehe. Ich habe das Mantis2Go installiert, ohne die darin enthaltenen Daten sieht es genauso aus wie das Mantis Bugtracker 1.2.11 auf einer linuxbasierten Oberfläche. In beiden Fällen sind ohne Datenimporte die Status änderbar. Meintest du das damit?

[atrol]

Also das Dump ist größer als 1,2 GB.

Ziemlich groß, ich nehme an, dass die Dateianhänge auch in der Datenbank gespeichert sind.
Vielleicht wird's wesentlich kleiner wenn man die Datei komprimiert.

Ich bin mir nicht sicher ob ich dich richtig verstehe. Ich habe das Mantis2Go installiert, ohne die darin enthaltenen Daten sieht es genauso aus wie das Mantis Bugtracker 1.2.11 auf einer linuxbasierten Oberfläche. In beiden Fällen sind ohne Datenimporte die Status änderbar. Meintest du das damit?

Ja, ich hatte gehofft mit ein paar Anweisungen der folgenden Art wäre die Geschichte nachvollziehbar
1. Lege ein öffentliches Projekt an
2. Mache die folgenden Einträge in config_inc.php
3. Konfiguriere die Arbeitsablauf-Schwellenwerte wie folgt (manage_config_work_threshold_page.php)
4. Lege einen User als Entwickler an
5. Erfasse einen Fall als Administrator
6. Versuche den Fall dem Entwickler zuzuordnen

[docbt]

Ja, ich hatte gehofft mit ein paar Anweisungen der folgenden Art wäre die Geschichte nachvollziehbar
1. Lege ein öffentliches Projekt an
2. Mache die folgenden Einträge in config_inc.php
3. Konfiguriere die Arbeitsablauf-Schwellenwerte wie folgt (manage_config_work_threshold_page.php)
4. Lege einen User als Entwickler an
5. Erfasse einen Fall als Administrator
6. Versuche den Fall dem Entwickler zuzuordnen

Das ist es ja, nichts der Gleichen ruft diesen Effekt auf. Erst mit dem Einfügen der alten Datenbank verschwindet die Auswahl zum Wechseln des Status.

[atrol]

Ich weiß nicht wie wichtig die Geschichte ist.
Entweder ihr bleibt erst Mal auf 1.1.8, oder ihr geht auf 1.2.10, wo das Problem nicht auftritt und geht zu einem späteren Zeitpunkt z.B. auf 1.2.12
Möglicherweise tritt das Problem in nächster Zeit noch bei anderen Usern leicht nachvollziehbar auf, so dass es in einer Version > 1.2.11 gefixt wird.
Ist natürlich alles reine Spekulation.

Ansonsten bleibt nur der Dump.

[docbt]

Vielen Dank erstmal.

Ich werde noch ein wenig testen, ich wollte nochmal die Datenbank jeweils in die nächst höhere Version Importieren vielleicht bringt es ja was. Sobald ich was erreiche melde ich mich.

[docbt]

Anonsten habe ich zumindest mal das Problem mit der Statuszuweisung reproduziert
und gelöst:
In Verwaltung > Konfiguration verwalten > Konfigurationsreport den folgenden
Eintrag löschen
Alle Benutzer Alle Projekte status_enum_workflow complex

Vielen Dank. Das war das Problem.

[atrol]

Damit es auch für andere hier im Zusammenhang nachvollziehbar und verständlich bleibt:
Mir wurde heute der Datenbankdump zur Analyse zur Verfügung gestellt. Die Antwort zur Lösung des Problems stammt aus einer privaten Mail.