Conference management site for FOSSY. Forked from Linux Australia's version at https://gitlab.com/laconfdev/symposion_app.
Find a file
James Polley ddae8d91f6 Improved handling of static/build and css generation
When the container is mounted, the local contents of . obscure
/app/symposion_app in the image.

Generally speaking, this is handy for development, as it means that
local changes are detected and used immediately without needing to
restart the container.

However, it breaks in the specific case of the sass->css
generation. Prior to this change, the css is generated only after the
first time a page is hit. The generated file is placed in
static/build; however, due to the obscuration, this generated file
isn't visible to the running process.

The next time the container is built, the pre-existing static/build
directory is copied into the container as it's being built; then,
later, that version is what gets served.

This change adds the needed libraries to pre-generate the css as part
of the image build, and runs compilescss to do this, prior to the
collectstatic step.

It also adds a second collectstatic into the make_dev_container
script, so that the visible static/build directory should ahve the
same contents as the obscured static/build directory. It also expands
the .dockerignore file to make sure these files aren't copied into the
image in future.

I'm not sure if this is the right thing to do, as changes to this
directory will be ignored, which could be confusing. Perhaps never
being able to see these generated files is better?
2018-06-06 12:20:06 +10:00
docker Improved handling of static/build and css generation 2018-06-06 12:20:06 +10:00
docs Fix duplicate room-slot in sample data 2017-10-15 15:31:20 +10:00
fixtures Update fixtures for LCA2019 2018-06-04 20:51:03 +12:00
pinaxcon Add first 2019 design attempts 2018-06-04 20:54:51 +12:00
static Add first 2019 design attempts 2018-06-04 20:54:51 +12:00
vendor Merge branch 'master' into ticket-testing 2018-04-17 15:54:38 +10:00
.dockerignore Improved handling of static/build and css generation 2018-06-06 12:20:06 +10:00
.gitignore Kludge tox to run flake8 2017-03-31 11:54:46 +11:00
.gitlab-ci.yml Attempt updated CI deployment 2018-05-26 14:47:19 +10:00
constraints.txt dj-gapc-storage fix for num_retries went upstream 2017-09-15 10:06:49 +10:00
dev-env.sh DATABASE_URL as ENV_VAR 2017-06-24 15:59:46 +10:00
LICENSE added MIT license 2016-04-26 17:18:28 +08:00
make_dev_container.sh Improved handling of static/build and css generation 2018-06-06 12:20:06 +10:00
manage.py Initial commit of the PinaxCon demo site 2015-10-16 12:53:02 -05:00
README.rst Utilise multi-stage docker build for consistent dev/prod base 2017-10-04 20:43:01 +11:00
requirements.txt Improved handling of static/build and css generation 2018-06-06 12:20:06 +10:00
TODO Quick todolist writeup 2018-06-04 20:55:04 +12:00
tox.ini Use full imports not . 2017-04-29 14:28:48 +10:00
vendored_requirements.txt Create regidesk app 2018-01-06 11:38:06 +11:00

symposion_app
=============

.. contents::

At this time, considerations have not been made to have the django project run
without additional infrastructure.

This can be configured in the future by switching the default
DEFAULT_FILE_STORAGE django default, and properly configuring django to load
subsequent configuration to switch this back to GCS on run in our testing
and production environments.

Login is a bit more complicated, the default flow redirects you out to a SAML
server, you can probably work something out with testshib.   But if you go to
/admin and log in, that will persist into /dashboard.


Required Configuration
----------------------

GCS
~~~

1. Set the bucket in settings.py
1. Store your Service Account JSON in a file
1. Set GOOGLE_APPLICATION_CREDENTIALS to your account file
1. Set GCS_BUCKET to your bucket name

SAML2
~~~~~

Please familiarise yourself with Shibboleth configuration and the general
flow of how to register a SP with an IDP.

If you send the SP metadata statically, validity time must be removed.

You will also need to register your IDP metadata here either statically or
remotely updated.

You may consider testing with testshib.

Configure signing and encryption keys, and configure them in the settings.py

Running a dev instance in Docker
--------------------------------

Assuming you have docker installed and working on your machine::
    ./make_dev_container.sh

will build you a container and run through the initial setup steps.
The last stage interactively creates a superuser account: you'll need
to interact with this for it to finish.

Once this has completed, you can hit http://localhost:28000/admin to
log into the admin interface. Once you're logged in,
http://localhost:28000 will take you to the dashboard.

Note that when you do this you're logged in as a superuser, so what
you see will be different from what a normal user will see.

Making migrations
~~~~~~~~~~~~~~~~~

If you make changes to the data model, you'll need to run "manage.py
makemigrations" to create a matching migration file. If you're on a
mac, or a system without python3, this can be difficult.

In such a case, you can use the above script to make and run a dev
container; then::
    docker exec -it symposion ./manage.py makemigrations


Running a dev instance in a VirtualEnv
--------------------------------------

Not all things are lovely, so we use constraints to force the versions we
we wish for without having to do anything ugly.  This may require a newer
version of pip than is packaged with distros virtualenv.

Note that this application is python 3 only so you must create your virtualenv
with a python3 interpreter.

- ``python3 -m venv venv``
- ``source ./venv/bin/activate``
- ``pip install -c constraints.txt -r requirements.txt``
- ``pip install -c constraints.txt -r vendored_requirements.txt``

Once your dev instance is up and running
----------------------------------------

Pre-post-start configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Now that we are ready to start the app, we need to do initial setup, start
it, perform voodoo string magic, run more database jingling voodoo, and then
we can start it up and start looking around and customising the application.

``./manage.py migrate``
``./manage.py runserver``

Now we hit up the admin interface, find `symposion_proposals` `proposalkind`
and add `Talk` slug `talk`, `Tutorial`:`tutorial`, and `Miniconf`:`miniconf`.

Shut down and now run:
``./manage.py populate_inventory``

Now you can run the system and see how it goes.

Admin tasks
-----------

Admin Credentials
~~~~~~~~~~~~~~~~~

To create a local administrator account run:

``./manage.py createsuperuser``

and enter your username, email and password. This can then be used to login to: (http://localhost:8000/admin).

Base Data
~~~~~~~~~

On initial creation and whenever you reset the database you must reload the
basic data. This data is stored in the /fixtures directory. You can load this with:

``./manage.py loaddata ./fixtures/{conference,proposal_base,sites,sitetree}.json``

And to load the base admin users:

``./manage.py loaddata ./fixtures/admin_users.json``

admin1:Inq4JVQyQvWnqXDI

admin2:w0jYMJsM4S+1zHds

admin3:XzynbNH9Sw3pLPXe

Creating review permissions objects
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

After conference Sections have been created, this command will add
Permission objects for those sections.

``./manage.py create_review_permissions``