Iguana

TL;DR

In contrast to other state-of-the-art ticket systems, iguana has a strong focus on easily usable basic functions to help you planing the next schedule and have always a nice overview about your current tasks depending on your needs. There is a kanban board to keep an eye on the progress until the end of the next planning stage and also a backlog to have the ability for scheduling of long-terms. In combination with a mechanism to log time spent on different tasks individually those are the essential functionalities.

Terms

To clarify this description some terms that we use shall be explained here.

Features

The content behind this listing might become the reason for you to use iguana. :)

Limitations

As stated out previously, iguana focuses on the basic tools one need to manage a project with multiple developers. This means the hierarchy in general is flat and there are neither subtasks nor subprojects, but they are all on the same level. Even though the hierarchy is flat there is the possibility to create some dependencies between different tasks and theoretically the same applies for projects for example by choosing a unique preposition to sort projects by groups. But in case you really need sub-{issues,projects} iguana might not be the best tool for you.

Demonstration

The demonstration section is separated from this page to avoid a confusing bunch of information. If you want to jump directly to a specific section see the navigation above.

Known issues

• The markdown functionality is not that handy as we wish yet and has some formatting issues.
• Stripping of image meta information is done only for jpeg right now.
• Some testcases throw multiple errors because some packages are deprecated. Until we have time to fix this see make test-ign_imp_errors to ignore them.
• Search for attachment titels is not possible yet.
• For the development settings the url that is send in the pw-reset-email is wrong.
• The short names of projects are unique and limited to a max_length of four, which might be a problem for long term support or when many people want to create projects with the same short name or even if one would like to host iguana for the public. Therefore we might add an owner to each project to create the possibility to use the same short names multiple times, once for each owner. So the short name won't be unique for itself anymore. This is a possible solution, but we haven't decided yet whether we implement this or another one.

Plan of the future

• Fix remaining security and privacy issues
• We might restructure the internal representation on how projects are unique and might bind that to a specific user to provide more freedom
• This will probably the moment we finally can release a version that is called a proper 1.0 and where we are going to ...
• Also at this moment we plan to introduce a proper change history
• migrate to the latest django version
• Integrations for additional messenger
• Extend api-support to be able to send requests either from command line or from an integrated messenger
• Keyboard support - until then Vimperator can be used
Update: Unfortunately this is not true anymore with the new firefox update because the overlay is not shown.
• An individual scratchpad for each user
• add additional languages - german is going to be the first language we support next to english. For any additional ones we require the help of the community
• Extend the notification properties for both new notification types and notification ways (currently only email is implemented as possible selection)
• Minor improvements
• Filter functionality for the activity stream
• A history for comments
• A changelog for Issues
• Automatized usage of security scanner
• Implement escaping for control characters of the olea-bar to be able to use those in the issue title, description etc. Currently this is only possible via the issue create/edit form.
• Integrate the olea-bar into the issue detail page to be able to modify the current issue in a more comfortable way.

Questions and answers

Is it possible to use iguana locally without the necessity to setup nginx?

Yes, therefore you can use the development environment (see Development) and adjust some values within the settings files like CAPTCHA_TEST_MODE, EMAIL_BACKEND etc.

Is it possible to use postgreSQL locally instead of the default SQLite?

Yes, this requires a few steps though.
Attention: This is not about migrating a SQLite database to postgreSQL or vice versa.

1. Install the required package for that

   
   sudo apt-get install postgresql-server-dev-11
   echo "psycopg2==<version>" >> requirements/development.req
   						

2. create the database

   
   # postgres is the actual system user
   sudo -u postgres createdb <name of your database>
   						

3. optionally import a dump from an existing postgres database

   
   sudo -u postgres psql <name of your database> < <your database dump file>
   					

4. create a new postgres user You might as well simply use the user postgres for this. But I like to create a separate user for a each database.

   
   sudo -u postgres create <your new postgres user for this project>
   sudo -u postgres psql
   # The password must not be empty
   postgres=# alter user <your new postgres user for this project> with
                         encrypted password '<password for your new postgres user>';
   						

5. Change the DATABASES entry in the local_conf.py

   
   # important: port needs to be empty and password must not be empty
   DATABASES = {
   	'default': {
   		'ENGINE':    django.db.backends.postgresql_psycopg2',
   		'NAME':     '<name of your database>',
   		'USER':     '<your new postgres user for this project>',
   		'PASSWORD': '<password of your new postgres user - must not be empty>',
   		'HOST':     'localhost',
   		'PORT':     '',
   	}
   }
   						

6. finalize and run

   
   # recreate the development to get the new dependencies and add the new database
   make development
   make migrate
   make run
   					

TODO?

TODO

Thanks

Our special thanks go to Florian Harbecke who was part of our team for about one month and especially to Philipp Klein for the initial guidance and the introduction to web development.