Apply stricter checks for session timestamps

[wkurniawan07]

Problem Statement

Currently, the check for session opening/closing/visible times are far too lenient:

• It allows setting the timestamps into a very distant past or a very distant future (big legacy mistake done in past sample courses!).
• It allows unrestricted session length, which hardly have any real world use.
• It allows setting of timestamps which are not at the exact hour mark.

This is the main reason, if not the sole reason, for:

• The usage statistics feature (#11618) to stop short of collecting hourly feedback session-related statistics.
• The need for sent*Email fields in order to determine whether said emails should be sent, instead of just matching the time with the 1-hour period when the cron job is triggered. On top of unnecessarily complicating DB entity design, this also contributes to #9125.
  • Notably, this was also exacerbated by improper timezone/DST handling in the past, but this is no longer happening now.

Solution

Suggested restrictions, baseline, ranked with priorities:

• (high) Opening time cannot be set sooner than (now + 1 hour) or later than (now + 90 days).
• (high) Closing time cannot be set sooner than (now + 1 hour) or later than (now + 180 days).
• (medium) Session length cannot be longer than 180 days. Note that this is also pending validity check, i.e. there are no legitimate sessions (not malicious, not misconfigured) that run for longer than that.
• (low) Opening/closing time must be set at exact hour mark.
• (low) Session visible time cannot be set sooner than (opening time - 30 days).

Note also some use cases that will require the above baseline to be adjusted:

• Copying sessions/courses; is the same validity check going to be applied, particularly for opening/closing times?
• Sometimes instructors want to see how a session that is already open/closed look like. We may want to allow very recent past (e.g. just 1-2 hours before now), but not any sooner than that.
  • This, by right, should be a different requirement, e.g. "test-only sessions" (e.g. an additional flag in feedback sessions), but at the moment all options are still to be considered.

[damithc]

• Copying sessions/courses; is the same validity check going to be applied, particularly for opening/closing times?

We might have to adjust the workflow of copying sessions to accommodate these constraints. Currently, the a copy of the session is saved with the original details first and then the dates are to be adjusted manually using a regular session-edit operation. This will conflict with the proposed constraints as the original session start/end dates can very well be in the past. Perhaps we can adjust the workflow as follows:

1. The user clicks the 'copy button', and chooses the target course(s) in the next modal.
2. The user is presented with a copy of the session details in edit mode, for tweaking any details as necessary (dates can be adjusted at this step).
3. The user clicks the 'save' button to save the copied session. This will be same as saving a new session.

[xyliew25]

@wkurniawan07 @damithc

I have some doubts that I would like to clarify:

1. It allows setting of timestamps which are not at the exact hour mark.

Doesn't the current allowed setting of timestamps at the exact hour mark, or am I interpreting the term 'exact hour mark' wrongly?

2. Sometimes instructors want to see how a session that is already open/closed look like. We may want to allow very recent past (e.g. just 1-2 hours before now), but not any sooner than that.

Does this mean instructors may want to create feedback sessions that are already open/closed?

[wkurniawan07]

Doesn't the current allowed setting of timestamps at the exact hour mark, or am I interpreting the term 'exact hour mark' wrongly?

The UI does restrict it, but the API does not. There's a big difference there.

[damithc]

Does this mean instructors may want to create feedback sessions that are already open/closed?

Yes, that's correct.

[u6867511]

Hello, the pull request above seems to be on hold until December. Could I have a go at this issue in the meantime?

[fsgmhoward]

@u6867511 Please work on other issues allocated to you first. The original author has not given up this.