Statusing Breaks

The purpose of this work was to enable the Gantt user to be able to see when a break has been started, and when it has been completed. The ability to set up colours for use in these circumstances has been added, and, by use of the Fix Break Time SOAP API the system can now provide the appropriate information to the Gantt such that the breaks can be coloured accordingly.

Controlling Gantt Horizon

The number of Gantt clients connected to a system, and the horizon over which they are viewing, can both have an effect on the performance of the system as a whole. It may, therefore, be necessary to restrict the Gantt horizon for certain users so that their use of the Gantt does not adversely effect other users. To this end, the capability of pre-setting a default horizon for Gantt users has been added. With the right permissions, this can be overridden so that those who need a longer horizon can have one, but the majority of users are restricted to a minimum.

Dispatching Breaks as Separate Entities

When a job or standard activity overlaps a break the break is 'subsumed' into the job or SA and durations etc. are updated accordingly. Earlier versions of the product also Dispatched these jobs/SAs and breaks together, so there was only one dispatch message rather than 2 separate ones. This way of working has cause some amount of confusion with regards to the rules applied to inform lead time etc. and the behaviour when a job changes/moves such that the break is no longer subsumed.

To help clarify these rules it is now the case that all breaks are dispatched separately - they are never dispatched as part of a job.

From a Gantt perspective the only differences seen will be that it may be possible to have an unearmarked break within an earmarked job or SA. From a Mobility perspective the mobile client will need to handle the case in the same way as it previously handled standalone breaks.