Bug 38195 - Not possible to select upcoming time slot for "Distribute materials"
Not possible to select upcoming time slot for "Distribute materials"
Product: UCS@school
Classification: Unclassified
Component: UMC - Distribution
UCS@school 4.0
Other Linux
: P5 normal (vote)
: UCS@school 4.0 R2
Assigned To: Florian Best
Alexander Kramer
Depends on:
  Show dependency treegraph
Reported: 2015-04-02 23:50 CEST by Michael Grandjean
Modified: 2015-05-11 19:24 CEST (History)
2 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional): Usability
Max CVSS v3 score:


Note You need to log in before you can comment on or make changes to this bug.
Description Michael Grandjean univentionstaff 2015-04-02 23:50:00 CEST
In the "Distribute materials" module of UCS@school I am able to select a "Distribution time" for the automatic distribution of my files. However, it's not possible to select the next available time slot (15 minute steps).


It's 10:38. I want to automatically distribute files at the next available time slot wich is "10:45". When clicking on "Create project", an error message appears:

"The specified time needs to lie in the future for: Project distribution"

That's reasonable, but in this case "10:45" *is* in the future. 

Clarification: Selecting a time slot that lies ahead another 15 minutes or more (e.g. "11:00", "11:15" ... ) is working fine.

This was discovered by an UCS@school workshop attendee today.
Comment 1 Sönke Schwardt-Krummrich univentionstaff 2015-04-09 10:18:29 CEST
This is somewhat tricky:

the time of browser and UMC server have to be in sync otherwise effects like the message above may occur (the server checks the given distribution time against its local server time). In UCS@school test environments this often occurs after using/reverting to snapshots.

# make sure the execution time lies sufficiently (5min) in the future
if getattr(project, jprop) - datetime.now() < timedelta(minutes=5):
    raise ValueError(_('The specified time needs to lie in the future for: %s') % 
The code currently requires the distribution time to be at least 5min in the future. If the distribution time is only a few seconds away from real time, the at job may not be called automatically.

I think we should reduce this timedelta to 0 seconds. If the requested distribution time is less than e.g. 65 seconds in the future, the distribution time is moved to rounduptofullminutes(now+65 seconds):
now==10:12:20  distrib_time==10:20:00  →  new_distrib_time=10:20:00
now==10:12:20  distrib_time==10:13:00  →  new_distrib_time=10:14:00
now==10:12:54  distrib_time==10:13:00  →  new_distrib_time=10:14:00
now==10:12:55  distrib_time==10:13:00  →  new_distrib_time=10:15:00
now==10:12:57  distrib_time==10:14:00  →  new_distrib_time=10:15:00
now==10:13:00  distrib_time==10:13:00  →  new_distrib_time=10:15:00

The new distribution time should also be saved at the project file.
Comment 2 Sönke Schwardt-Krummrich univentionstaff 2015-04-09 10:20:45 CEST
Please also alter the collection time code:
a) the timedelta of 10 minutes should be removed 
   current code: collection - distribution >= 10min
b) the collection time has to be at least 1 min after the (possibly corrected) 
   distribution time.
Comment 3 Florian Best univentionstaff 2015-04-17 14:59:56 CEST
The timedelta of 10 minutes has been reduced to 3 minutes (nobody will collect after 2 minutes).

The start time can now be 1 minute in the future.

Fix: svn r59708
Package: ucs-school-umc-distribution
Comment 4 Alexander Kramer univentionstaff 2015-04-21 11:08:05 CEST
OK - time delta 3min for automatic collection
OK - time delta 65sec for automatic distribution
OK - debian /changelog
OK - r60009 Adapted the changelog xml to
Comment 5 Florian Best univentionstaff 2015-05-11 19:24:53 CEST
UCS@school 4.0 R2 v1 has been released:

If this error occurs again, please use "Clone This Bug".