Adding an "accessible_period" dict to define start and end period.

… accessibility and registration

Courses will now use a dictionnary for "accessible_period" and "registration_period" with a start and end element. Tasks will have an "accessibility_period" dict with an extra soft_end element.

…ccessibility/registration structure

…k settings form

…in DB

Putting boolean and period dict inside one element : "accessibility": {"is_open": bool, "period": {"start": ..., "soft_end": ..., "end": ...}}. This way dispenser_data["config"] init in TableOfContents does not have to be changed.

…nd DB

To keep the same structure as the task accessibility (dict with bool and period dict).

When initiating task_config from yaml we give a default value if there are missing values. When these values are dictionnaries they are actually all the same. Modifying one will modify all of them. Therefor we give an new instance at each default value to allow transformation into strings before rendering.  Also had a mixup on the transformation itself.

Adding representer to use !!timestamp tag in yaml for datetime objects. Moving string transformation in datetime before changing taskset yaml file. Fixing datetime transformation to datetime before toc.html render (was permanently changing task_config).

Structure made in previous commits was not valid due to the way other method of this class work. Values for the dates could be None. Resulting in errors when comparing NoneType and datetime objects.

Plus fixing bug : When deleting tasks in course edit, the missing tasks were added back (check_dispenser_data function) with default parameters. Default date parameter beeing None it wasn't correctly handled by the date conversion (dispenser_data_str_to_datetimes function).

+ fixing dispenser_config not passed to render

Changing their name and structure to allow transformation of strings and dates inside python list.

…me for use in templates

Was setting up AccessibleTime to use datetime objects for the period dates. But in the templates the task_config is parsed in JSON and it can't parse datetime objects. So whe transform the dates into strings before render. AccessibleTime needs to be able to handle string dates because of it's use in the templates.

…y settings from task yaml

Was checking the accessibility settings as they were using the new structure (in DB or taskset.yaml). But when checking if the tasks have legacy settings in their task.yaml it raises an exception because the legacy accessibility has the old structure.

The boolean "is_open" is not really used. Instead we now only use the start, soft_end and end date. We will differenciate the access types by setting some dates to a minimal or maximal value. For example : a task that is always open will have a minimal start date and maximal soft_end and end dates.
In the custom acces mode, the dates are now optional. You can for example set an end date without setting a start date because it will automatically be set to the minimal value.

The dates are stored in MongoDB as ISODate() objects and we will use datetime.min and datetime.max in python code for minimal and maximal values. However, MongoDB stores dates with a precision to the millisecond. Datetime objects have a precision to the nanosecond. Therefor we have some transformations when retrieving dates from mongoDB (in AccessibleTime).

…sform minimal date

When using the timestamp representer to transform datetime objects into strings with "!!timestamp" tags, the date.min caused problems. The zeros in front of the 1 (0001-01-01 00:00:00) would not be considered when using datetime.strftime(). It would simply delete the zeros causing the date to not have the correct structure for the timestamp.

…n already custom accessibility

When changing a task accessibility (soft_end or end) that was already custom an error occured when saving the changes. It was because there was no check if the input value is an empty string.

dict_data_str_to_datetime was not operating correctly because the strings were already transformed in datetime objects when checking for the data. Adapted AccessibleTime parse_date() and not using dict_data_str_to_datetime anymore.

…ing legacy courses

+ moving dict_data_str_to_datetime()

…enser

Changing access structure of tasks when importing in course template and task edit. Also moving change_access_structure, dict_data_str_to_datetime and dict_data_datetimes_to_str in util file in frontend directory.

… of DB

…Time

…ecific one

… feed

Fixing previous commit

+ course_factory method used on taskset_factory

…ility()

…nto strings

Had years with less than 4 digits not transformed into strings with years without leading "0" characters.

Simplifying 4 digit year check + removing empty string check because can only be applied to datetime objects

…seconds

Storing as min and max attributes of AccessibleTime when possible. And using dates without microseconds

by adding boolean, empty string and None values

…stration date

+ fix None value and empty string

…ting settings instead of legacy migration

…date

…egacy update"

This reverts commit d03a4e9.

…tasks settings update

Previously done when importing legacy tasks

…handling

…ructure_to_dict()

for removing accessibility structure from task import

…ot given

+ fixing dispenser_config not passed to render

…me for use in templates

Was setting up AccessibleTime to use datetime objects for the period dates. But in the templates the task_config is parsed in JSON and it can't parse datetime objects. So whe transform the dates into strings before render. AccessibleTime needs to be able to handle string dates because of it's use in the templates.

Locales were not working for datetimepickers because the loacales were not defined. moment-with-locales.min.js contains those locales.

Had a problem when retrieving taskid in accessibility.html. It is passed to the button on the opening of the modal. However they are two events triggered by that opening. The one where defaultDate are given to the datetimepicker triggers first. And the change in value triggers another event using taskid. Therefor taskid wass accessed before being passed as data.

…anaged and stored in DB

… form submit

Before submitting the form the dates in datetime pickers are transformed from the user's timezone to UTC (timezone used for the server dates).

Indicating the dates received are UTC and retrieving UTC datetime.now() for correct comparison.

…n checking accessibility

Error previously fixed on access_tructure branch but reapeared due to bad rebase.

Because the modal is only one HTML code block we update with new data, datetime pickers need to be destroyed are recreated with the new defaultDate. This is the only option found to apply the timezone. Changing the date with datetimepicker('date', ...) does not take timezone into consideration.

Recreating the datetime picker triggers the change event listeners. Added a 'ignore-change' value to pickers to avoid updating the dispenser_config on modal feed.

…datetime pickers

…hecking custom

During grouped edit one could select dates and apply the changes without selecting the "custom" radio check.

…submissions query

When using viewDate to retrieve date on empty picker it sent the creation date of that picker. Using date instead.

…troying each time it needs change

… Tempus Dominus

…hange datetime pickers to Flatpickr

Managed to delete event listeners on individual date pickers. Contrary to Tempus Dominus. The change through picker and through input change are both triggered by one event listener.

…ckr as datetime picker

…ickers

Wrong class

…led on taskset object

We were storing still open courses as they were already past due.

Using datetime objects as dictionnary keys will change depending on if a timezone was given. If a timezone is given the key will have an offset in addition to the date and time. In our case, adding the utc timezone to the c key solves the problem.

Was transforming moment objects to Javascript Date objects. However these Date objects do not hold timezone data and define the date with a local timezone.

…pt scoreboard plugin to user's timezone

Exchanging keys and values for easier manipulation in html.

…ity under each task

…te() and adapt_database_date()

to fix test_parsable_text tests + fixes (not applying timezone to min and max dates)

…in user data

…() method