taskjuggler 3.1.0 → 3.2.0

data/lib/tj3webd.rb

@@ -0,0 +1,17 @@
+#!/usr/bin/env ruby -w
+# encoding: UTF-8
+#
+# = tj3webd.rb -- The TaskJuggler III Project Management Software
+#
+# Copyright (c) 2006, 2007, 2008, 2009, 2010, 2011, 2012
+#               by Chris Schlaeger <chris@linux.com>
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of version 2 of the GNU General Public License as
+# published by the Free Software Foundation.
+#
+
+require 'taskjuggler/apps/Tj3WebD'
+
+exit TaskJuggler::Tj3WebD.new.main()
+

data/manual/Day_To_Day_Juggling

@@ -315,6 +315,7 @@ data for ''''tj3ts_sender'''' to your TaskJuggler configuration file.
 The time sheet related settings have their own top-level section:
 
  _global:
+   emailDeliveryMethod: smtp
    smtpServer: smtp.your_company.com
    authKey: topsecret
    scmCommand: "svn add %f ; svn commit -m '%m' %f"
@@ -329,10 +330,15 @@ The time sheet related settings have their own top-level section:
      digestRecipients:
        - managers@your_company.com
 
+The ''''emailDeliveryMethod'''' defines how emails should be sent.
+Use ''''smtp'''' to directly send the emails to an SMTP server.
 The ''''smtpServer'''' defines which host will handle your emails. Replace the
-host name with your local SMTP server. The 'scmCommand' setting contains the
-command to add and commit new and old files to the source code management
-system. The command in this example works for Subversion.
+host name with your local SMTP server. Alternatively, you can use the
+method ''''sendmail'''' on UNIX-like systems to pass the email to the
+sendmail tool. In this case, the ''''smtpServer'''' line can be
+omitted. The 'scmCommand' setting contains the command to add and
+commit new and old files to the source code management system. The
+command in this example works for Subversion.
 
 The TaskJuggler server may serve multiple projects. With the
 ''''projectId'''' option you have to specify which project you would
@@ -545,6 +551,7 @@ used. Before you can use it, you need to add a few settings to the
 TaskJuggler configuration file.
 
  _global:
+   emailDeliveryMethod: smtp
    smtpServer: smtp.your_company.com
    authKey: topsecret
    projectId: prj

data/manual/Installation

@@ -275,12 +275,18 @@ downloaded.
   tar -Zxvf ruby-X.X.X-*.tar.gz
 
 This will create a directory with the same name as the archive, but
-without the ''''.tar.gz'''' extension. Now change into this directory
-and configure the source code for your specific OS and compile it.
-For this to work, you need to have the GNU C compiler and related
-utilities installed. We configure Ruby to append ''''19'''' to all
-executable names. This way, you can easily choose if you want to run
-the old or the new Ruby. ''''ruby'''' runs your distribution Ruby,
+without the ''''.tar.gz'''' extension. 
+
+Before you continue, make sure you have all the necessary packages
+installed to compile ruby. That would be everything you need to
+compile C programs. That includes gcc, make, zlib and libyaml. If
+something is missing, you will run into problems in the next 2 steps.
+It's sometimes not obvious which package to install to fix the issue.
+
+Now change into this directory and configure the source code for your
+specific OS and compile it. We configure Ruby to append ''''19'''' to
+all executable names. This way, you can easily choose if you want to
+run the old or the new Ruby. ''''ruby'''' runs your distribution Ruby,
 ''''ruby19'''' runs your new ruby.
 
   cd ruby-X.X.X-*
@@ -293,6 +299,30 @@ will be installed into ''''/usr/local/bin''''.
 
   sudo make install
 
+The TaskJuggler front-end scripts always use the ''''ruby''''
+interpreter that's the first in the PATH. You need to set a link in
+your local ''''bin'''' directory to point to your ''''ruby19''''
+executable as ''''ruby''''. 
+
+  ln -s /usr/local/bin/ruby19 ${HOME}/bin/ruby
+
+Make sure your ''''${HOME}/bin'''' directory is the first directory in
+the ''''PATH''''. This step varies a lot depending on the login
+shell. E. g. for ''''bash'''' put the following at the end in your
+''''.profile'''' shell config file. Please make sure that
+''''/usr/local/bin'''' is also in the PATH so that the ruby
+executables (all having a ''''19'''' suffix) will be found as well.
+
+  export PATH=${HOME}/bin:${PATH}
+
+Log out and back in again. Now
+
+  which ruby
+
+should show return the path to the link to your
+''''${HOME}/bin/ruby''''. You now have the latest Ruby installed and
+are ready to use TaskJuggler.
+
 As a final step, you need to install the ''''mail'''' and
 ''''term-ansicolor'''' gems.
 
@@ -303,17 +333,6 @@ install the TaskJuggler gem as well.
 
   sudo gem19 install taskjuggler
 
-The TaskJuggler front-end scripts always use the ''''ruby''''
-interpreter that's the first in the PATH. You need to set a link in
-your local ''''bin'''' directory to point to your ''''ruby19''''
-executable as ''''ruby''''. Make sure your ''''${HOME}/bin''''
-directory is the first directory in the ''''PATH''''.
-
-  ln -s /usr/local/bin/ruby19 ${HOME}/bin/ruby
-
-That's it. You now have the latest Ruby installed and are ready to
-use TaskJuggler.
-
 === Installing the Vim Support ===
 
 TaskJuggler can be used with any text editor that supports UTF-8 text
@@ -364,11 +383,11 @@ should have the following features available:
   must be the first non-blank character of the last line of the
   block. See the '''':help fold'''' Vim help command for details how
   to open and close folds.
-* Tag navigation. If you include a [tagfile] report in your project,
+* Tag navigation. If you include a [[tagfile]] report in your project,
   Vim will know all property IDs and can jump to them. If you have a
   task with the ID ''''foo.bar'''', the command '''':ta foo.bar''''
   will put the cursor right where task ''''foo.bar'''' was declared.
-* ID completion. If you include a [tagfile] report in your project,
+* ID completion. If you include a [[tagfile]] report in your project,
   Vim can tell you the full hierarchical ID of a property. Just move
   the cursor to the first line of the property definition and press
   ''''Ctrl-]''''.

data/manual/Software

@@ -91,9 +91,8 @@ get this user manual (browser).
 
 ''''tj3d'''' is the TaskJuggler daemon. It is a program that runs
 in the background, disconnected from your shell to provide certain
-services. It can generate reports on demand and serves them as web
-pages to a web browser. It's also used to process incoming time
-sheets.
+services. It can generate reports on demand and processes incoming
+time sheets or status reports.
 
 Depending on the size of your project the scheduling time can take
 several minutes or more. Since all operations need to be done on the
@@ -157,22 +156,6 @@ the ''''-c'''' option. See
 
 for details.
 
-The daemon can also be turned into a web server that serves the HTML
-reports of one or more projects. To enable the web server, start the
-daemon with the ''''-w'''' option. By default, the web server is
-listening on port 8080. This can be changed in the ''''_global''''
-section of the config file.
-
- _global:
-   authKey: topsecret
-   webServerPort: 8080
-
-To access the HTML reports point your web browser to
-''''http://localhost:8080/taskjuggler''''. This assumes that the
-server is running on your local machine. You will then see a list of
-all loaded projects. Click on the project name to get a list of all
-reports for this project.
-
 So far, the daemon has not received any kind of security review. We
 strongly advise you to only use the daemon in a trusted environment
 with only trusted users!
@@ -213,5 +196,28 @@ A server that is running can be terminated with the following command.
 
  tj3client terminate
 
+=== ''''tj3webd'''' ===
+
+This is a web server to serve the HTML reports of a project to any
+web browser. The HTML reports are generated on the fly when accessed.
+''''tj3webd'''' requires that ''''tj3d'''' is already running on the
+same machine.
+
+By default, the web server is listening on port 8080. This can be
+changed in the ''''_global'''' section of the config file.
+
+ _global:
+   authKey: topsecret
+   webServerPort: 8080
+
+To access the HTML reports point your web browser to
+''''http://localhost:8080/taskjuggler''''. This assumes that the
+server is running on your local machine. You will then see a list of
+all loaded projects. Click on the project name to get a list of all
+reports for this project.
 
+''WARNING: Please be aware that the web server when you have started
+it can be accessed by anybody on your local machine and by anybody
+that can reach your machine over the network! It will serve all
+reports of all projects that are hosted by the TaskJuggler daemon.''
 

data/manual/Tutorial

@@ -1,50 +1,54 @@
 == The Tutorial: Your first Project ==
 
 We have mentioned already that TaskJuggler uses plain text files that
-describe the project to schedule it. As you will see now, the syntax
+capture the known parts of the project. As you will see now, the syntax
 of these files is easy to understand and very intuitive. This chapter
 will walk you step by step through your first project. You create the
 project plan for a made-up accounting software project. This project
-demonstrates some of the commonly used features of TaskJuggler. The
-complete example can be downloaded
-[http://www.taskjuggler.org/tj3/examples/Tutorial/tutorial.tjp here]. The
+demonstrates most of the commonly used features of TaskJuggler. It
+also includes some of the more advanced concepts that you may or may
+not need for your projects. Don't get scared by them. You can use
+them once you are more familiar with TaskJuggler and your projects
+grow larger. The complete tutorial example can be downloaded
+[http://www.taskjuggler.org/tj3/examples/Tutorial/tutorial.tjp here].
+You can use any plain text editor to view and modify it.  The
 resulting reports can be found
-[http://www.taskjuggler.org/tj3/examples/Tutorial/Overview.html
-here].
+[http://www.taskjuggler.org/tj3/examples/Tutorial/Overview.html here].
 
 === Starting the project ===
 
-To start a TaskJuggler project file you need to use the [[project]]
+Every TaskJuggler project file must start with the [[project]]
 property. It tells TaskJuggler the name of your project and a start
 and end date. The start and end dates don't need to be exact, but must
-fit all tasks of the project.  It is the time interval the TaskJuggler
+fit all tasks of the project. It is the time interval the TaskJuggler
 scheduler will use to fit the tasks in. So, make it large enough for
 all your tasks to fit in. But don't make it too large, because this
 will result in longer scheduling times and higher memory consumption.
 
 <[example file="tutorial" tag="header1"]>
 
-All TaskJuggler properties have two required attributes, a unique ID
-and a name, and a set of optional attributes. The name must always be
-specified. The ID can be omitted if you never have to reference the
-property from another context. If you omit the ID, TaskJuggler will
-automatically generate a unique ID. The other optional attributes are
-always enclosed in curly braces. If no optional attributes are
-specified, the braces can be omitted as well. In this example we will
-introduce a number of there attributes that may or may not matter to
-you. If you don't see an immediate need for a specific attribute, feel
-free to ignore it for now. You can always come back to them later. A
-full list of the supported attributes can be found in the
-''attributes'' section of the [[project]] property documentation.
-
-Attributes always start with a keyword that is unique in the context.
-A context is delimited by a set of curly braces that enclose optional
-attributes of a property. The area between properties is called the
-global scope.  Usually, attributes have one or more arguments. These
-arguments can be dates, character strings, numbers or symbols. Strings
-must be enclosed in single or double quotes. The argument types and
-meaning is explained for each keyword in the syntax reference section
-of this manual.
+All TaskJuggler properties have a unique ID ,a name, and a set of
+optional attributes. The name must always be specified. The ID can be
+omitted if you never have to reference the property from another
+context. If you omit the ID, TaskJuggler will automatically generate a
+unique ID. The optional attributes are always enclosed in curly
+braces. If no optional attributes are specified, the braces can be
+omitted as well. In this example we will introduce a number of the
+attributes that may or may not matter for your specific projects. If
+you don't see an immediate need for a specific attribute, feel free to
+ignore it for now. You can always come back to them later. A full list
+of the supported project attributes can be found in the ''attributes''
+section of the [[project]] property documentation.
+
+Attributes always start with a keyword that identifies them.  The
+meaning and parameters of attributes depends on the property context
+that they are used in. A context is delimited by a set of curly
+braces that enclose optional attributes of a property. The area
+outside of any property is called the global scope.  Usually,
+attributes have one or more arguments. These arguments can be dates,
+character strings, numbers or symbols. Strings must be enclosed in
+single or double quotes. The argument types and meaning is explained
+for each keyword in the syntax reference section of this manual.
 
 TaskJuggler manages all events with an accuracy of up to 15 minutes.
 In many cases, you don't care about this level of accuracy.
@@ -62,7 +66,7 @@ See [[interval2]] for details.
 
  project acso "Accounting Software"  2002-01-16-0:00-+0100
 
-The [[currency]] attribute specifies the unit of currency values.
+The [[currency]] attribute specifies the unit of all currency values.
 
 <[example file="tutorial" tag="currency"]>
 
@@ -70,7 +74,7 @@ Because each culture has its own way of specifying dates and numbers,
 the format for these are configurable.  Use the [[timeformat]]
 attribute to specify the default format for dates. This format is used
 for reports, it does not affect the way you specify dates in the
-project files. Here you always need to use the [[date|ISO standardized
+project files. Here you always need to use the [[date|TaskJuggler date
 notation]].
 
 <[example file="tutorial" tag="formats"]>
@@ -79,9 +83,9 @@ We also can specify the way numbers or currency values are shown in
 the reports. Use the [[numberformat]] and [[currencyformat]]
 attributes for this.
 
-The optional attribute [[now]] is used to set the current day for the
+The attribute [[now]] is used to set the current day for the
 scheduler to another value than to the moment your invoke TaskJuggler.
-When this attribute is not present, TaskJuggler will use the current
+If this attribute is not present, TaskJuggler will use the current
 moment of time to determine where you are with your tasks. To get a
 defined result for the reports in this example we've picked a specific
 date that fits our purpose here. In your projects, you would use
@@ -92,16 +96,17 @@ date that fits our purpose here. In your projects, you would use
 In this tutorial we would like to compare two scenarios of the
 project. The first scenario is the one that we have planned. The
 second scenario is how it really happened. The two scenarios have the
-same task structure, but the start and end dates of the task may vary.
-In reality we assume that the project got delayed, so we call the
-second scenario "Delayed". The scenario property is used to specify
-the scenarios. The delayed scenario is nested into the plan scenario.
-This tells TaskJuggler to use all values from the plan scenario also
-for the second scenario unless the second scenario has it's own
-values. This is a very easy but also powerful way to analyze the
-impact of certain changes to the plan of record.  We'll see further
-below, how to specify values for a scenario and how to compare the
-results.
+same task structure, but the start and end dates and other attributes
+of the task that are scenario specific may vary. In this example we
+assume that the project got delayed and use a second scenario that we
+name "Delayed" to describe the actual project. The scenario property
+is used to specify the scenarios. The delayed scenario is nested into
+the plan scenario.  This tells TaskJuggler to use all values from the
+plan scenario also for the second scenario unless the second scenario
+has it's own values. This is a very easy but also powerful way to
+analyze the impact of certain changes to the plan of record.  We'll
+see further below, how to specify values for a scenario and how to
+compare the results.
 
 <[example file="tutorial" tag="scenario"]>
 
@@ -120,36 +125,34 @@ daily costs of an employee. This can be changed for certain employees
 later, but it illustrates an important concept of TaskJuggler –
 inheritance of attributes. In order to reduce the size of the
 TaskJuggler project file to a readable minimum, properties inherit
-many optional attributes from their enclosing scopes. We'll see
-further below, what this actually means. Right after the project
-property we are at top-level scope, so this is the default for all
-following properties.
+many attributes from their enclosing scopes. We'll see further below,
+what this actually means. Right after the project property we are at
+top-level scope, so this is the default for all following properties.
 
 <[example file="tutorial" tag="rate"]>
 
 The [[rate]] attribute can be used to specify the daily costs of
-resources. All subsequent resources will get this rate. But it can be
-changed to a different rate at group or individual resource level.
+resources. All subsequently declared resources will get this rate. But
+it can certainly be changed to a different rate at group or individual
+resource level.
 
 You may also want to tell TaskJuggler about holidays that affect
-all resources. Global vacations are time periods where TaskJuggler
+all resources. Global holidays are time periods where TaskJuggler
 does not do any resource assignments to tasks.
 
 <[example file="tutorial" tag="vacation"]>
 
-Use the [[vacation]] attribute to define a global vacation. Global
-vacations must have a name and a date or date range. This is slightly
-different from vacations of individual resources. They are defined
-with the [[vacation.resource|vacation attribute for resources]] where
-the name is optional. The vacation name is purely for documentation
-purposes.
+Use the [[leaves]] attribute to define a global holiday. Global
+holidays may have a name and must have a date or date range. Other leaves for
+individual resources or groups of resources can be defines similarly.
 
 === Macros ===
 
-Macros are another TaskJuggler feature to keep project files small.
-Macros are text patterns that can be defined once and inserted
-multiple times in the project file. A [[macro]] always has a name and the
-text pattern is enclosed by square brackets. 
+Macros are another TaskJuggler feature to save you typing work and to
+keep project files small and maintainable. Macros are text patterns
+that can be defined once and inserted multiple times in the project
+file. A [[macro]] always has a name and the text pattern is enclosed
+by square brackets. 
 
 <[example file="tutorial" tag="macro"]>
 
@@ -162,22 +165,22 @@ pattern.
 === Declaring Flags ===
 
 A TaskJuggler feature that you will probably make heavy use of is
-flags. Once declared you can attach them to many properties. When you
+flags. Once declared you can attach them to any property. When you
 generate reports of the TaskJuggler results, you can use the flags to
-filter out information and limit the report to exactly those details
-that you want to have included.
+filter out unwanted properties and limit the report to exactly those
+details that you want to have included.
 
 <[example file="tutorial" tag="flags"]>
 
-This is flag declaration. All [[flags]] need to be declared, before they
-can be used to avoid hard to find errors due to misspelled flag
-names. The flags should be declared shortly below the project header.
-We will see further down, how we can make use of these flags.
+This is a [[flags]] declaration. All flags need to be declared before
+they can be used to avoid hard to find errors due to misspelled flag
+names. The flags should be declared before any property at global
+scope. We will see further down, how we can make use of these flags.
 
 === Declaring Accounts ===
 
-The use of our resources will create costs. For a profit and loss
-analysis, we need to balance the costs against the customer payments.
+The use of our resources will generate costs. For a profit and loss
+analysis, we need to balance the cost against the customer payments.
 In order not to get lost with all the various amounts, we declare 3
 [[account|accounts]] to credit the amounts to. We create one account
 for the development costs, one for the documentation costs, and one
@@ -185,14 +188,12 @@ for the customer payments.
 
 <[example file="tutorial" tag="accounts"]>
 
-Like all TaskJuggler properties, the account needs an ID and a name.
-IDs may only consist of the characters a to z, A to Z and the
-underscore. All but the first character may also be digits 0 to 9.
-All global TaskJuggler properties have IDs. The ID is necessary so
-that we can reference the property again later without having to write
-the potentially much longer name. The name may contain space
-characters and therefore has to be enclosed with single or double
-quotes.
+The account needs an ID and a name.  IDs may only consist of the
+characters a to z, A to Z and the underscore. All but the first
+character may also be digits 0 to 9. The ID is necessary so that we
+can reference the property again later without having to write the
+potentially much longer name. The name may contain space characters
+and therefore has to be enclosed with single or double quotes.
 
 Accounts can be grouped by nesting them. You can use this feature to
 create sets of accounts. Such sets can then be balanced against each
@@ -211,11 +212,11 @@ project.
 <[example file="tutorial" tag="resources"]>
 
 This snippet of the example shows the use of the [[resource|
-resource property]]. Just like accounts, resources always have an ID
-and a Name. These IDs also need to be unique within their property
-class.  Names are strings and as such enclosed in double quotes. As
-you can see, resource properties can be nested: ''''dev'''' is a group
-or container resource, a team that consists of three other resources.
+resource property]]. Just like accounts, resources should have an ID
+and must have a name. Resource IDs, like account IDs must also be
+unique within their property class. As you can see, resource
+properties can be nested: ''''dev'''' is a group or container
+resource, a team that consists of three other resources.
 
 ''''dev1'''', alias Paul Smith, costs more than the normal employee.
 So the declaration of ''''dev1'''' overwrites the inherited default
@@ -224,34 +225,42 @@ rate with a higher value.
 The default value has been inherited from the enclosing scope,
 resource ''''dev'''', which in turn has inherited it from the global
 scope.  The declaration of the resource Klaus Müller uses another
-optional attribute. With vacation you can specify a certain time
-interval where the resource is not available. Vacations are list
-attributes. They accumulate the declarations. If you want to get rid
-of inherited values, you can use the [[purge]] attribute to clear the
+optional attribute. Attributes are only inherited from the parent
+property if the attribute was declared in the parent property before
+the child property declaration was started.
+
+The syntax reference lists for each property whether an attribute is
+inherited from the parent or the attribute in the global scope.
+
+With [[leaves]] you can specify certain time intervals where the
+resource is not available. Leaves are list attributes. They accumulate
+the declarations. If you want to get rid of inherited or previously
+assigned values, you can use the [[purge]] attribute to clear the
 list.
 
-It is important that you understand how TaskJuggler handles time
-intervals.  Internally, TaskJuggler uses the number of seconds after
-January 1st, 1970 to store any date.  So all dates are actually stored
-with an accuracy of 1 second in UTC time. ''''2002-02-01'''' specifies
-midnight February 1st, 2002. Following the TaskJuggler concept of
-requiring as little information as necessary and extending the rest
-with sensible defaults, TaskJuggler adds the time 0:00:00 if nothing
-else has been specified. So the vacation ends on midnight February
-5th, 2002. Well, almost. Every time you specify a time interval, the
-end date is not included in the interval. So Klaus Müller's vacation
-ends exactly at 0:00:00 on February 4th, 2002.
+''''leaves'''' requires a time interval. It is important to understand
+how TaskJuggler handles time intervals.  Internally, TaskJuggler uses
+the number of seconds after January 1st, 1970 to store any date.  So
+all dates are actually stored with an accuracy of 1 second in UTC
+time. ''''2002-02-01'''' specifies midnight February 1st, 2002.
+Following the TaskJuggler concept of requiring as little information
+as necessary and extending the rest with sensible defaults,
+TaskJuggler adds the time 0:00:00 if nothing else has been specified.
+So the vacation ends on midnight February 5th, 2002. Well, almost.
+Every time you specify a time interval, the end date is not included
+in the interval. So Klaus Müller's vacation ends exactly at 0:00:00 on
+February 5th, 2002. February 5 is not part of the leave!
 
 Peter Murphy only works 6.4 hours a day. So we use the
 [[limits.resource|limits]] attribute to limit his daily working hours.
 We could also define exact working hours using the [[shift|shift
 property]], but we ignore this for now.
 
-Note that we have attached the flag team after the declaration of the
-sub-resources to the team resources.  This way, these flags don't get
-passed down to the sub-resources. If we would have declared the flags
-before the sub-resources, then they would have the flags attached as
-well.
+Note that we have attached the flag ''''team'''' after the declaration
+of the sub-resources to the team resources.  This way, these flags
+don't get passed down to the sub-resources. If we would have declared
+the flags before the sub-resources, then they would have the flags
+attached as well.
 
 === Specifying the Tasks ===
 
@@ -259,7 +268,7 @@ Let's focus on the real work now. The project should solve a problem:
 the creation of an accounting software. Because the job is quite
 complicated, we break it down into several subtasks. We need to do a
 specification, develop the software, test the software, and write a
-manual. Using the [[task|task property]], thiis would look as follows:
+manual. Using the [[task|task property]], this would look as follows:
 
 <[example file="tutorial" tag="task1"]>
 
@@ -296,7 +305,7 @@ resources could be allocated long enough to reach the specified
 effort. Tasks with ''''length'''' or ''''duration'''' criteria and
 allocated resources will last exactly as long as requested. Resources
 will be allocated only if available. It's possible that such a tasks
-ends up with no allocations at all since the resources are always
+ends up with no allocations at all if the resources are always
 assigned to other tasks for that period. Each task can only have one
 of the three duration criteria. Container tasks may never have a
 duration specification. They are automatically adjusted to fit all
@@ -310,13 +319,9 @@ expression ''''${allocate_developers}'''' is simply expanded to
 If you need to [[allocate]] the same bunch of people to several tasks,
 the macro saves you some typing. You could have written the allocate
 attributes directly instead of using the macro. Since the allocation
-of multiple resources to a task is a very common place for macro
+of multiple resources to a task is a good place for macro
 usage, we found it a good idea to use it in this example as well.
 
-One more interesting thing to note is the fact that we like the
-resource ''''dev2'''' only to work 4 hours each day on this task, so
-we use the optional attribute [[limits.resource]] to specify this.
-
 For TaskJuggler to schedule a task, it needs to know either the start
 and end criteria of a task, or one of them and a duration
 specification. The start and end criteria can either be fixed dates or
@@ -324,7 +329,7 @@ relative dates. Relative dates are specifications of the type ''task B
 starts after task A has finished''. Or in other words, task B depends
 on task A. In this example the spec task depends on a subtasks of the
 deliveries task. We have not specified it yet, but it has the local ID
-start.
+''''start''''.
 
 To specify the dependency between the two tasks, we use the
 [[depends]] attribute. This attribute must be followed by one or more
@@ -370,6 +375,10 @@ the AcSo scope that contains the spec tasks. For a change, we
 
 <[example file="tutorial" tag="gui"]>
 
+One more interesting thing to note is the fact that we like the
+resource ''''dev2'''' only to work 6 hours each day on this task, so
+we use the optional attribute [[limits.resource]] to specify this.
+
 TaskJuggler can schedule your project for two different [[scenario|
 scenarios]]. We have called the first scenario ''''plan'''' scenario
 and the second ''''delayed'''' scenario. Many of the reports allow you