The wizard is used instead of the normal built-in creation workflow
It consists of multiple steps to specify the most fundamental settings (especially the timezone), further settings, copying AKCategories and AKRequirements from existing events and activating the event once the basic configuration is done
The steps after the creation (first two steps) can be skipped

Update timezone-field and add pytz to requirements, add matching migration

See merge request kif/akplanning!93

Previously, the version of pytz was not fixed. This could lead to problems when the list of timezones of the locally installed version of pytz differed from the list fixed in migration 0027 of AKModel. This commit therefore:
* updates django-timezone-field to the newest version
* Adds pytz with the current version to requirements.txt
* Introduces a migration to reflect the changes in the internal timezone list of pytz (--('America/Godthab', 'GMT-03:00 America/Godthab'), ++('America/Nuuk', 'GMT-03:00 America/Nuuk'), --('Australia/Currie', 'GMT+11:00 Australia/Currie'))

Introduce manage view for ak tracks

Closes #112

See merge request kif/akplanning!90

Benjamin Hättasch authored 4 years ago and Nadja Geisler committed 3 years ago

This view can be used to sort aks into tracks using drag and drop. You can also create new ak tracks or delete them.

Add js dependency for drag and drop of lists.
Activate add, update, delete methids to AKTrack API and update method to AK API.
Add and link (on status page) new admin view for management.
Add tags list property to AK model.
Introduce translations for AKScheduling app.
Update translations.

Fix API detail views

See merge request kif/akplanning!89

Benjamin Hättasch authored 4 years ago and Nadja Geisler committed 3 years ago

Previously, the event from the url was not parsed correctly for API endpoints for individual AKs, AKRooms, etc. This led to self.event being None and the queryset being empty, hence the AK, AKRoom etc. could not be found by the API. This fix makes sure, the event is loaded as part of the API initialization for all endpoints and methods.

Do not track changes of AK interest counter

Closes #97

See merge request kif/akplanning!86

Add new view
Link on status page

This fixes #97
Exclude interest_counter from AK history
Prevent saving of history record when increasing interest counter

Run the following action after applying the change/migration to remove existing duplicate history records (the ones without changes to tracked fields, hence caused by either saving without changing any field or especially the ones created due to changes of the now ignored interest_counter):
python manage.py clean_duplicate_history AKModel.ak

Verbose name of AKSlot.fixed was updated in a previous commit, this migration reflects this change

Reintroduce locale setting for fullcalendar views

See merge request kif/akplanning!85

Reintroduce the locale settings that where falsely removed in !74 (afa4558a and 10667a08) -- while this setting is not needed in fc version 3 that the merge request referred to, stating them explicitly is needed in v5 that is used in our project currently.

set different color accents in admin interface when deployed for production

See merge request kif/akplanning!82

Fc fix update

Closes #111

See merge request kif/akplanning!84

This resolves #111

Move background event color to scheduling init code instead of every single background event

Use name field instead of default string representation of AK in header field
Add some margin below to improve visual appearance

Update dependencies

See merge request kif/akplanning!83

Use django debug toolbar

See merge request !81

Benjamin Hättasch authored 4 years ago and Nadja Geisler committed 4 years ago

Add requirement
Adjust settings to load toolbar in debug mode
Add debug URLs

Improvements to fullcalendar loading

See merge request !74

Nils Steinger authored 4 years ago and Benjamin Hättasch committed 4 years ago

This removes support for the explicit "locale: '{{ LANGUAGE_CODE }}'" setting,
but that should not be a problem as https://fullcalendar.io/docs/v3/locale
states:
> If you are simply loading one locale, you do not need to specify the locale
> option.

Use more pythonic way to calculate times and construct strings