|
If you were logged in you would be able to see more operations.
|
|
|
ILOG Elixir
Created: 10/Apr/08 06:24 PM
Updated: 29/Apr/09 03:50 PM
|
|
| Component/s: |
Product
|
| Affects Version/s: |
None
|
| Fix Version/s: |
None
|
|
| Module / SubModule: |
Gantt
|
|
Currently all resources share the same definition of working and nonworking days.
The new feature would consist in allowing each resource to have its own work calendar.
Shared and specific calendars:
Work calendars are generally composed of a shared part and a specific part. For example the shared part stores the definition of working and nonworking periods for the country of a person, while the specific part corresponds to vacations of this person.
This structure allows to simplify the definition of the work calendars.
The specific calendars adds nonworking periods to the shared calendar. It should also allow to define exceptions to the nonworking periods defined by the shared calendar (e.g.: a person is exceptionnaly working during a week-end, a holiday...).
|
|
Description
|
Currently all resources share the same definition of working and nonworking days.
The new feature would consist in allowing each resource to have its own work calendar.
Shared and specific calendars:
Work calendars are generally composed of a shared part and a specific part. For example the shared part stores the definition of working and nonworking periods for the country of a person, while the specific part corresponds to vacations of this person.
This structure allows to simplify the definition of the work calendars.
The specific calendars adds nonworking periods to the shared calendar. It should also allow to define exceptions to the nonworking periods defined by the shared calendar (e.g.: a person is exceptionnaly working during a week-end, a holiday...). |
Show » |
|
New Feature
Open
Major
Allow each resource to have its own work calendar
In the back-end we attach a calendar/roster (mostly a cyclic roster with night shifts aso) for each resource using an XML description and some logic (Team, place of employment,...). This is then translated to "pseudo" tasks in the data provider and show-up on the gantt chart. In our case we also include "real" tasks in the roster definition for recurring tasks for specific resources.
Problem is the amount of tasks that need to be transfered over the wire, converted from java objects to flex objects, drawing on the gantt chart, which causes performance problems.
One solution could be to configure in advance the gantt chart with the necessary roster/calendar definitions (including renderers for the specific "periods" that are defined in the definition).
Here is an example of one of the XML definitions we are using, the ID attributes control the way things are rendered/visualized (color, height, y-position)
<?xml version="1.0" encoding="UTF-8"?>
<tns:roster startday="1" cycle="true"
xmlns:tns="http://www.brabo.com/RosterDefinition"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.brabo.com/RosterDefinition RosterDefinition.xsd ">
<tns:pattern>
<tns:unit repeat="5">
<tns:fixedperiod id="NONWORK" starttime="00:00:00"
endtime="08:29:00" />
<tns:slidingperiod id="WORK" startrangefrom="08:30:00"
startrangeto="09:29:00" endrangefrom="12:00:00"
endrangeto="13:29:00" />
<tns:slidingperiod id="LUNCH" startrangefrom="12:00:00"
startrangeto="13:29:00" endrangefrom="13:30:00"
endrangeto="13:59:00" minimumduration="PT30M" />
<tns:slidingperiod id="WORK" startrangefrom="12:30:00"
startrangeto="13:59:00" endrangefrom="16:00:00"
endrangeto="17:29:00" />
<tns:fixedperiod id="NONWORK" starttime="17:30:00"
endtime="23:59:00" />
</tns:unit>
<tns:unit repeat="2">
<tns:fixedperiod id="WEEKEND" starttime="00:00:00"
endtime="23:59:00" />
</tns:unit>
</tns:pattern>
</tns:roster>
.