Stalker

=======

* **Fix:** Fixed a bug in ``Task`` class where trying to remove the
dependencies will raise an ``AttributeError`` caused by the
``Task._previously_removed_dependent_tasks`` attribute.

=======

* **New:** Task instances now have two new properties called ``path`` and
``absolute_path``. As in Version instances, these are the rendered version
of the related FilenameTemplate object in the related Project. The ``path``
attribute is Repository root relative and ``absolute_path`` is the absolute
path including the OS dependent Repository path.

* **Update:** Updated alembic revision with revision number "433d9caaafab" to
also create Statuses introduced with Stalker v0.2.5.

=======

* **Update:** ``Version.__repr__`` results with a more readable string.

* **New:** Added a generalized generator called
``stalker.models.walk_hierarchy()`` that walks and yields the entities over
the given attribute in DFS or BFS fashion.

* **New:** Added ``Task.walk_hierarchy()`` which iterates over the hierarchy of
the task. It walks in a breadth first fashion. Use ``method=0`` to walk in
depth first.

* **New:** Added ``Task.walk_dependencies()`` which iterates over the
dependencies of the task. It walks in a breadth first fashion. Use
``method=0`` to walk in depth first.

* **New:** Added ``Version.walk_hierarchy()`` which iterates over the hierarchy
of the version. It walks in a depth first fashion. Use ``method=1`` to walk
in breadth first.

* **New:** Added ``Version.walk_inputs()`` which iterates over the inputs of
the version. It walks in a depth first fashion. Use ``method=1`` to walk in
breath first.

* **Update:** ``stalker.models.check_circular_dependency()`` function is now
using ``stalker.models.walk_hierarchy()`` instead of recursion over itself,
which makes it more robust in deep hierarchies.

* **Fix:** ``db.init()`` now updates the statuses of already created status
lists for ``Task``, ``Asset``, ``Shot`` and ``Sequence`` classes.

=====

* **Update:** ``Revision`` class is renamed to ``Review`` and introduced a
couple of new attributes.

* **New:** Added a new workflow called "Task Review Workflow". Please see the
documentation about the new workflow.

* **Update:** ``Task.responsible`` attribute is now a list which allows
multiple responsible to be set for a ``Task``.

* **New:** Because of the new "Task Review Workflow" task statuses which are
normally created in Stalker Pyramid are now automatically created in Stalker
database initialization. The new statuses are
**Waiting For Dependency (WFD)**, **Ready To Start (RTS)**,
**Work In Progress (WIP)**, **Pending Review (PREV)**,
**Has Revision (HREV)**, **On Hold (OH)**, **Stopped (STOP)** and
**Completed (CMPL)** are all used in ``Task``, ``Asset``, ``Shot`` and
``Sequence`` status lists by default.

* **New:** Because of the new "Task Review Workflow" also a status list for
``Review`` class is created by default. It contains the statuses of
**New (NEW)**, **Requested Revision (RREV)** and **Approved (APP)**.

* **Fix:** ``Users.login`` column is now unique.

* **Update:** Ticket workflow in config is now using the proper status names
instead of the lower case names of the statuses.

* **New:** Added a new exception called **StatusError** which states the entity
status is not suitable for the action it is applied to.

* **New:** ``Studio`` instance now stores the scheduling state to the database
to prevent two scheduling process to override each other. It also stores the
last schedule message and the last schedule date and the id of the user who
has done the scheduling.

* **New:** The **Task Dependency** relation is now using an
**Association Object** instead of just a **Secondary Table**. The
``Task.depends`` and ``Task.dependent_of`` attributes are now
*association_proxies*.

Also added extra parameters like ``dependency_target``, ``gap_timing``,
``gap_unit`` and ``gap_model`` to the dependency relation. So all of the
dependency relations are now able to hold those extra information.

Updated the ``task_tjp_template`` to reflect the details of the dependencies
that a task has.

* **New:** ``ScheduleMixin`` class now has some default class attributes that
will allow customizations in inherited classes. This is mainly done for
``TaskDependency`` class and for ``the gap_timing``, ``gap_unit``,
``gap_model`` attributes which are in fact synonyms of ``schedule_timing``,
``schedule_unit`` and ``schedule_model`` attributes coming from the
``ScheduleMixin`` class. So by using the ``__default_schedule_attr_name__``
Stalker is able to display error messages complaining about ``gap_timing``
attribute instead of ``schedule_timing`` etc.

* **New:** Updating a task by calling ``Task.request_revision()`` will now set
the ``TaskDependency.dependency_target`` to **'onstart'** for tasks those are
depending to the revised task and updated to have a status of **DREV**,
**OH** or **STOP**. Thus, TaskJuggler will be able to continue scheduling
these tasks even if the tasks are now working together.

* **Update:** Updated the TaskJuggler templates to make the tjp output a little
bit more readable.

* **New:** ``ScheduleMixin`` now creates more localized (to the mixed in class)
column and enum type names in the mixed in classes.

For example, it creates the ``TaskScheduleModel`` enum type for ``Task``
class and for ``TaskDependency`` it creates ``TaskDependencyGapModel`` with
the same setup following the ``{{class_name}}{{attr_name}}Model`` template.

Also it creates ``schedule_model`` column for ``Task``, and ``gap_model`` for
``TaskDependency`` class.

* **Update:** Renamed the ``TaskScheduleUnit`` enum type name to ``TimeUnit``
in ``ScheduleMixin``.

=====

* **New:** Added new class called ``Revision`` to hold info about Task
revisions.

* **Update:** Renamed ``ScheduleMixin`` to ``DateRangeMixin``.

* **New:** Added a new mixin called ``ScheduleMixin`` (replacing the old one)
which adds attributes like ``schedule_timing``, ``schedule_unit``,
``schedule_model`` and ``schedule_constraint``.

* **New:** Added ``Task.tickets`` and ``Task.open_tickets`` properties.

* **Update:** Removed unnecessary arguments (``project_lead``, ``tasks``,
``watching``, ``last_login``) from User class.

* **Update:** The ``timing_resolution`` attribute is moved from the
``DateRangeMixin`` to ``Studio`` class. So instances of classes like
``Project`` or ``Task`` will not have their own timing resolution anymore.

* **New:** The ``Studio`` instance now overrides the values on
``stalker.defaults`` on creation and on load, and also the ``db.setup()``
function lets the first ``Studio`` instance that it finds to update the
defaults. So it is now possible to use ``stalker.defaults`` all the time
without worrying about the Studio settings.

* **Update:** The ``Studio.yearly_working_days`` value is now always an
integer.

* **New:** Added a new method ``ScheduleMixin.least_meaningful_time_unit()`` to
calculate the most appropriate timing unit and the value of the given seconds
which represents an interval of time.

So it will convert 3600 seconds to 1 hours, and 8424000 seconds to 1 years if
it represents working time (``as_working_time=True``) or 2340 hours if it is
representing the calendar time.

* **New:** Added a new method to ``ScheduleMixin`` called ``to_seconds()``. The
``to_seconds()`` method converts the given schedule info values
(``schedule_timing``, ``schedule_unit``, ``schedule_model``) to seconds
considering if the given ``schedule_model`` is work time based ('effort' or
'length') or calendar time based ('duration').

* **New:** Added a new method to ``ScheduleMixin`` called ``schedule_seconds``
which you may recognise from ``Task`` class. What it does is pretty much the
same as in the ``Task`` class, it converts the given schedule info values to
seconds.

* **Update:** In ``DateRangeMixin``, when the ``start``, ``end`` or
``duration`` arguments given so that the duration is smaller then the
``defaults.timing_resolution`` the ``defaults.timing_resolution`` will be
used as the ``duration`` and the ``end`` will be recalculated by anchoring
the ``start`` value.

* **New:** Adding a ``TimeLog`` to a ``Task`` and extending its schedule info
values now will always use the least meaningful timing unit. So expanding a
task from 16 hours to 18 hours will result a task with 2 days of schedule
(considering the ``daily_working_hours = 9``).

* **Update:** Moved the ``daily_working_hours`` attribute from ``Studio`` class
to ``WorkingHours`` class as it was much related to this one then ``Studio``
class. Left a property with the same name in the ``Studio`` class, so it will
still function as it was before but there will be no column in the database
for that attribute anymore.

=======

* **Fix:** Fixed a bug in ``stalker.models.auth.LocalSession`` where stalker
was complaining about "copy_reg" module, it seems that it is related to
`this bug`_.

.. _this bug: http://www.archivum.info/python-bugs-listpython.org/2007-04/msg00222.html