Files
Benbb96 59d04db027 test: assert the settings layers do not drift
Three static checks over files already in the repository, so they cost nothing
at runtime:

* every HELPDESK_/QUEUE_ name an example configuration assigns is a name
  src/helpdesk reads. HELPDESK_PUBLIC_ENABLED failed this for years.
* every environment variable the docs/standalone.rst tables promise is read
  from os.environ by standalone/config/settings.py. HELPDESK_KANBAN_ENABLED
  failed this. The check looks at the environment reads rather than the file
  text, so a name hardcoded in the configuration does not satisfy it while
  ignoring what the operator puts in docker.env.
* every key of a HELPDESK_DEFAULT_SETTINGS dict is a field on UserSettings.
  DEFAULT_USER_SETTINGS.update() merges whatever it is handed, so an unknown
  key is absorbed in silence.

Each check was verified to fail when its own regression is reintroduced, and
the third needed a cleanup to pass: "preset_replies" was in the standalone and
demo configurations and "email_on_ticket_apichange" in the demo one, neither is
a UserSettings field, and neither has ever been read. The name preset_replies
does exist elsewhere as a template context variable holding PreSetReply rows,
which is unrelated and probably how it got there. HELPDESK_PRESET_REPLIES goes
from the standalone documentation table with it, since the key it fed is gone.

The checks are tripwires rather than proofs: a name appearing only in a comment
counts as used, which is the right trade for catching a whole setting falling
out of use. They skip when run against an installed distribution, since they
need the repository layout.

Filed in #1416.
2026-09-05 00:16:53 +02:00
..
2025-08-19 23:20:34 +01:00

django-helpdesk Demo Project
============================

This folder contains a demo Django project that
illustrates a simple django-helpdesk installation
with common settings.

This project is *NOT* production ready, but can be
used as a template to get started.

In particular, this should be useful for testing
purposes and for those that want to contribute
to development of django-helpdesk. For more information
on contributing, see the CONTRIBUTING.rst file
in the top level of the django-helpdesk directory.

Running the demo
----------------

While not recommended, the simplest way to get
started is to simply install django-helpdesk
to your system python package directory.
Ideally, you'd use a virtualenv instead
(see below for details).

To use your system directory, from the top-level
django-helpdesk directory, simply run::

    make rundemo

Once the console gives a prompt that the HTTP
server is listening, open your web browser
and navigate to http://localhost:8080

You should see the django-helpdesk public web portal!

If you shut down the server, you can't immediately
re-run the demo because the make commands would
encounter problems trying to re-write the database.
Instead, before running the demo, you will need
to first clean the demo::

    sudo make distclean

You may need to use sudo with other make targets too.

*NOTE ON USING VIRTUALENV*

Rather than using the system python, you probably
want to use a virtualenv.

If so, you might change the pip in the makefile
to point to your virtualenv's pip instead
before running::

    make rundemo


*NOTE ON ATTACHMENTS*

The folder:

    demodesk/media/helpdesk/attachments

comes pre-populated with a couple of attachments,
to demo how django-helpdesk deals with attachments.
You can look in this folder to see the raw data.
You can also create a different folder for this
and update settings.py, but note that this will
break the demo as some attachments may not be available
unless you migrate the existing data to the
new location.

The demodesk project
--------------------

"demodesk" is the name of our demo Django project.

You probably will want to look at demodesk/config/settings.py
and read the comments, which walk you through a basic
installation with common configuration options.

The top-level Makefile also gives a list of commands so you
can see how to get the project running. Of course,
when you plan to deploy this project, it is recommended
to use a "real" HTTP server like apache or nginx,
and so further configuration will be necessary.

More information can be found in the top-level docs/ folder.