Posts Tagged ‘ Dev

Support für WCF 1.0/WBB3.0 Pakete eingestellt

Um mich aktuell mehr auf das WCF 1.1/WBB 3.1 und rechtzeitig auf das WCF 1.2/WBB 3.2 konzentrieren zu können, stelle ich ab heute den Support für alle meine WCF 1.0/WBB3.0 Pakete/Versionen ein. Die betroffenen Pakete bzw Paketversionen werden nicht mehr weiterentwickelt und erhalten auch keine Sicherheitsupdates mehr.

WCF 1.1/WBB 3.1 Versionen von Paketen, die auch WCF 1.0/WBB 3.0 Versionen haben sind selbstverständlich nicht betroffen.

Projekt „Icy Tracker“ – Das ACP lässt mich nicht los

Da dachte ich heute, ich könnte mich endlich gemütlich an das Formular zum erstellen von Vorgängen machen und wie ich mir so mittendrin Gedanken zur Anwendung der Rechte mache, merke ich, ich brauche doch eine Möglichkeit die Rechte pro Projekt genau einzustellen. Mit anderen Worten ich muss meine AccessList JavaScript-Klasse und alles, was mit dran hängt so erweitern, dass sie jetzt auch pro Eintrag Rechte oder allgemeiner gefasst Einstellungen erlaubt.
Ich würde ja WoltLabs Klassen dafür verwenden, aber die stehen leider unter der WBB Lizenz. Zudem möchte ich ungern auf die ganzen schönen Dinge, die mir Prototype 1.6 bietet verzichten.
Was das für den Icy Tracker bedeutet? Die Arbeiten am Frontend verzögern sich weiter und ich arbeite weiter am ACP. Ich hoffe ich schaffe es am Wochenende endlich was am Frontend zu machen. Um euch wieder ein wenig besser zu stimmen packe ich aber mal einen Screenshot von der (vorläufigen) Startseite im „WoltLab Basic“-Stil mit hier in den Artikel. Bedenkt aber, dass die Arbeiten an der Startseite noch nicht abgeschlossen sind und sich von daher noch einiges ändern kann.

Startseite (Vorschau)

Update: Projekt „Icy Tracker“ – Zugriff auf Projekte für Benutzer und Gruppen

Ich habe heute weitere Arbeiten am ACP gemacht und hoffe, dass ich damit vorerst alle Arbeiten am ACP beendet habe und mich voll und ganz auf das Frontend konzentrieren kann, an dem ich schon seit ein paar Tagen hätte arbeiten wollen. Man kann jetzt jedenfalls Benutzern und Gruppen Zugriff auf einzelne Projekte gewähren. Das ganze läuft wie bei den Entwicklern, nur dass hier halt zusätzlich Gruppen möglich sind.

Wie immer ein paar Bilder für Interessierte:

Update: Projekt „Icy Tracker“ – Gruppenrechte

Ich habe heute neben einigen Arbeiten an den Editor-Klassen und ein paar anderen Dingen die Gruppenrechte für vorhandene und auch kommende Funktionen komplett überarbeitet und mit Sprachvariablen ausgestattet.

Für Interessierte hier ein paar Screenshots zu den Rechten:

Update: Projekt „Icy Tracker“ – Neue Bilder vom ACP

Am Wochenende gab es ein paar Änderungen im ACP beim Anlegen und Bearbeiten von Projekten. Man kann nun einem Projekt Entwickler zuweisen. Vorerst nur einzelne Entwickler und keine Gruppen und auch die Rechteverwaltung für die Entwickler wird noch ganz normal über Gruppenverwaltung getätigt.
Neu ist auch, dass der Projektleiter nun auch Entwickler im Projekt sein muss. Deshalb wird der Entwickler nun mit einem Dropdown ausgewählt, welches dynamisch per JavaScript aus der Entwicklerliste befüllt wird.

Hier die Bilder zu den Änderungen:

Und weiter gehts

Blog

Ich habe heute mal, nachdem das Design nach dem Update auf WordPress 3.1 nicht mehr ganz so gut lief, mal das Design gewechselt. Ich hoffe euch gefällt der Blog im neuen Design.

Versionsverwaltung

Ich teste im Moment das Versionsverwaltungssystem Git und habe in dem Zuge 2 meiner öffentlichen SVN Repositories mal auf Git umgestellt (weitere folgen). Ich habe auch direkt einen ganz netten Repository viewer gefunden und hier installiert. Erreichen könnt ihr den Viewer unter http://codingcorner.info/cgit/ oder bequem über das Menü hier im Blog.

Icy Tracker

Auch, wenn ich in den letzten Monaten nicht wirklich Zeit für den Icy Tracker hatte: Die Arbeiten sind nicht eingestellt. Es wird weiter daran gearbeitet und ich hoffe, ich kann euch schon bald wieder mit neuen Screenshots erfreuen.

Update: Projekt “Icy Tracker” – Verknüpfungen zwischen Tickets/Issues

Da hab eich doch tatsächlich einen Status „Duplikat“ geplant, aber keine Verknüpfungen zwischen Tickets. Es wird selbstverständlich eine Verknüpfung geben.

Die Verknüpfung wird vom Elternticket, als auch vom Kindticket machbar sein. Folgende Verknüpfungstypen werden dabei möglich sein:

  • Hat abhängiges Ticket / Ist abhängig von
  • Hat Duplikat / Ist Duplikat von

Auch hier kann sich natürlich noch was ändern und ich freue mich über Vorschläge und Feedback eurerseits.

Update: Projekt „Icy Tracker“ – Erste Bilder vom ACP

Da ich an diesem Wochenende einiges geschafft habe, dachte ich mir, ich könnte euch ein paar erste Screenshots aus dem ACP mit auf den Weg geben.
Viel Spaß mit den Bildern.

Update: Projekt „Icy Tracker“

Da ich im Moment leider nicht die Zeit habe, die ich gerne in das Projekt rein stecken würde, habe ich mich dazu entschieden erst einmal eine „kleine“ Version zu schreiben, die nicht alle geplanten Features haben wird. Diese „kleine“ Version wird die 1.0 sein und den Codenamen „Gennam“ tragen, was Germanisch für „Anfang“ ist.

Gennam wird dabei so minimalistisch wie möglich gehalten. Es wird nur Projekte und keine Kategorien geben. Die Tickettypen werden fest sein, genauso wie die Prioritäten, die Status (Ja, das ist der Plural von Status), die Prioritäten und die Lösungen für geschlossene Tickets. Es wird keine Benutzerdefinierten Felder für Tickets geben und es steht noch nicht fest, ob man Tickets verknüpfen können wird, aber ich denke, das wird kommen.

Ein Ticket wird bestehen aus:

  • Titel / Kurzbeschreibung
  • Typ
  • Status
  • Priorität
  • Bearbeiter
  • Betroffene Version(en)
  • Lösung (wenn das Ticket geschlossen/behoben/umgesetzt wurde)
  • Version in der das Problem behoben/das Feature implementiert ist (wenn das Ticket geschlossen/behoben/umgesetzt wurde)
  • Sichtbarkeit (damit kritische Fehler nur für den „Melder“ und die Entwickler zu sehen sind)
  • Beschreibung

Zusätzlich werden sie Anhänge und Kommentare enthalten können und Feature Requests werden vermutlich zusätzlich eine „Möchte ich auch“-Funktion haben.

Die möglichen Tickettypen werden nach der aktuellen Planung folgende werden:

  • Bug/Fehler
  • Feature Request (kann mir jemand dafür eine korrekte und zugleich passende Übersetzung nennen?)
  • Aufgabe

Die Status werden nach der aktuellen Planung folgende werden:

  • Neu
  • Bestätigt
  • In Arbeit
  • Behoben/Umgesetzt
  • Geschlossen

Die Lösungen zu den Status Behoben/Umgesetzt und Geschlossen werden nach aktueller Planung wie folgt heißen:

  • Behoben
  • Lösung verschoben
  • Wird nicht behoben/umgesetzt
  • Nicht reproduzierbar
  • Kein Fehler
  • Duplikat

Die Prioritäten werden nach aktueller Planung wie folgt lauten:

  • Kritisch
  • Hoch
  • Normal
  • Niedrig
  • Keine

Die angegeben Typen, Status, Lösungen und Prioritäten können sich noch teilweise ändern und ich freue mich selbstverständlich auch über Anregungen. Vielleicht fällt euch ja noch der eine oder andere Status o.Ä. ein, welcher unbedingt noch mit rein muss.

Ich hoffe, ich konnte euch einen kleinen Überblick verschaffen. Wenn ihr noch fragen habt könnt ihr diese gerne als Kommentar oder an die im Impressum angegebene E-Mail Adresse stellen.

Projekt: Icy Tracker

Wie einige vielleicht wissen, gehöre ich zu den Leuten, die hohe Ansprüche an eingesetzte Software, wie zum Beispiel das eingesetzte Web-CMS oder den eingesetzten Bugtracker stellen. Zudem habe ich auch noch sehr genaue Vorstellungen, was ein solches System wie können sollte.

In den letzten Wochen stand ich bei den Überlegungen zu einigen nicht Open Source Projekten vor der Frage, welches Bug-/Issuetracking System dort eingesetzt werden soll. Meine Open Source Projekte supporte ich mit JIRA und an und für sich bin ich mit dem System zufrieden. Doch 8000 Dollar/Jahr für eine „unlimited user“-Lizenz kann und will ich mir beim besten Willen nicht leisten und in der Coding Corner verwenden wir eine Lizenz für Open Source Projekte, die kann ich also nicht mit verwenden.

Nach reichlicher Überlegung und Betrachtung der alternativen Systeme (Mantis, etc) war klar, das ein neues System her muss. Nach kurzer Überlegung habe ich mich für das WCF als Basis entschieden. Der vorläufige Name für das Projekt ist Icy Tracker (info.codingcorner.it). Die Planung werde ich weitestgehend öffentlich über die gerade von mir eingerichtete Dev-Wiki machen und soweit ich Zeit finde gelegentlich hier im Blog kommentieren.

Einen Zeitplan zur Entwicklung des Icy Tracker gibt es nicht und wird es vermutlich auch nicht geben, da sich die Zeit, die ich in das Projekt investieren kann sehr von meiner Arbeit und der Zeit, die ich zur Wartung eines anderen Projektes brauche, abhängig ist.