stalker.models.task.TaskDependency

class stalker.models.task.TaskDependency(task=None, depends_to=None, dependency_target=None, gap_timing=0, gap_unit=’h’, gap_model=’length’)

Bases: sqlalchemy.ext.declarative.api.Base, stalker.models.mixins.ScheduleMixin

The association object used in Task-to-Task dependency relation

__init__(task=None, depends_to=None, dependency_target=None, gap_timing=0, gap_unit=’h’, gap_model=’length’)

Methods

__init__([task, depends_to, …])
least_meaningful_time_unit(seconds[, …])	returns the least meaningful timing unit that corresponds to the
to_seconds(timing, unit, model)	converts the schedule values to seconds, depending on to the

Attributes

dependency_target	The dependency target of the relation.
depends_to
depends_to_id
gap_model	An enumeration value one of [“length”, “duration”].
gap_timing	A positive float value showing the desired gap between the dependent and dependee tasks.
gap_unit
metadata
plural_class_name	the plural name of this class
query
schedule_constraint	An integer number showing the constraint schema for this task.
schedule_model	Defines the schedule model which is going to be used by TaskJuggler while scheduling this Task.
schedule_seconds	Returns the schedule values as seconds, depending on to the schedule_model the value will differ.
schedule_timing	It is the value of the gap timing.
schedule_unit	It is the unit of the gap timing.
task
task_id
to_tjp	TaskJuggler representation of this TaskDependency

least_meaningful_time_unit(seconds, as_work_time=True)

returns the least meaningful timing unit that corresponds to the given seconds. So if:

as_work_time == True

seconds % (1 years work time as seconds) == 0 –> ‘y’ else: seconds % (1 month work time as seconds) == 0 –> ‘m’ else: seconds % (1 week work time as seconds) == 0 –> ‘w’ else: seconds % (1 day work time as seconds) == 0 –> ‘d’ else: seconds % (1 hour work time as seconds) == 0 –> ‘h’ else: seconds % (1 minutes work time as seconds) == 0 –> ‘min’ else: raise RuntimeError

as_work_time == False

seconds % (1 years as seconds) == 0 –> ‘y’ else: seconds % (1 month as seconds) == 0 –> ‘m’ else: seconds % (1 week as seconds) == 0 –> ‘w’ else: seconds % (1 day as seconds) == 0 –> ‘d’ else: seconds % (1 hour as seconds) == 0 –> ‘h’ else: seconds % (1 minutes as seconds) == 0 –> ‘min’ else: raise RuntimeError

Parameters:

• seconds (int) – An integer showing the total seconds to be converted.
• as_work_time (bool) – Should the input be considered as work time or calendar time.

Returns int, string:  

Returns one integer and one string, showing the timing value and the unit.

plural_class_name

the plural name of this class

schedule_constraint

An integer number showing the constraint schema for this task.

Possible values are:

0	Constrain None
1	Constrain Start
2	Constrain End
3	Constrain Both

For convenience use stalker.models.task.CONSTRAIN_NONE, stalker.models.task.CONSTRAIN_START, stalker.models.task.CONSTRAIN_END, stalker.models.task.CONSTRAIN_BOTH.

This value is going to be used to constrain the start and end date values of this task. So if you want to pin the start of a task to a certain date. Set its schedule_constraint value to CONSTRAIN_START. When the task is scheduled by TaskJuggler the start date will be pinned to the start attribute of this task.

And if both of the date values (start and end) wanted to be pinned to certain dates (making the task effectively a duration task) set the desired start and end and then set the schedule_constraint to CONSTRAIN_BOTH.

schedule_model

Defines the schedule model which is going to be used by TaskJuggler while scheduling this Task. It has three possible values; effort, duration, length. effort is the default value. Each value causes this task to be scheduled in different ways:

effort	If the schedule_model attribute is set to “effort” then the start and end date values are calculated so that a resource should spent this much of work time to complete a Task. For example, a task with schedule_timing of 4 days, needs 4 working days. So it can take 4 working days to complete the Task, but it doesn’t mean that the task duration will be 4 days. If the resource works overtime then the task will be finished before 4 days or if the resource will not be available (due to a vacation) then the task duration can be much more.
duration	The duration of the task will exactly be equal to schedule_timing regardless of the resource availability. So the difference between start and end attribute values are equal to schedule_timing. Essentially making the task duration in calendar days instead of working days.
length	In this model the duration of the task will exactly be equal to the given length value in working days regardless of the resource availability. So a task with the schedule_timing is set to 4 days will be completed in 4 working days. But again it will not be always 4 calendar days due to the weekends or non working days.

schedule_seconds

Returns the schedule values as seconds, depending on to the schedule_model the value will differ. So if the schedule_model is ‘effort’ or ‘length’ then the schedule_time and schedule_unit values are interpreted as work time, if the schedule_model is ‘duration’ then the schedule_time and schedule_unit values are considered as calendar time.

schedule_timing

It is the value of the gap timing. It is a float value.

The timing value can either be as Work Time or Calendar Time defined by the gap_model attribute. So when the gap_model is duration then the value of this attribute is in Calendar Time, and if the gap_model is either length or effort then the value is considered as Work Time.

schedule_unit

It is the unit of the gap timing. It is a string value. And should be one of ‘min’, ‘h’, ‘d’, ‘w’, ‘m’, ‘y’.

to_seconds(timing, unit, model)

converts the schedule values to seconds, depending on to the schedule_model the value will differ. So if the schedule_model is ‘effort’ or ‘length’ then the schedule_time and schedule_unit values are interpreted as work time, if the schedule_model is ‘duration’ then the schedule_time and schedule_unit values are considered as calendar time.

gap_timing

A positive float value showing the desired gap between the dependent and dependee tasks. The meaning of the gap value, either is it work time or calendar time is defined by the gap_model attribute. So when the gap model is “duration” then the value of gap is in calendar time, if gap is “length” then it is considered as work time.

gap_model

An enumeration value one of [“length”, “duration”]. The value of this attribute defines if the gap value is in Work Time or Calendar Time. The default value is “length” so the gap value defines a time interval in work time.

dependency_target

The dependency target of the relation. The default value is “onend”, which will create a dependency between two tasks so that the depending task will start after the task that it is depending to is finished.

The dependency_target attribute is updated to “onstart” when a task has a revision and needs to work together with its depending tasks.

to_tjp

TaskJuggler representation of this TaskDependency