This is an alternative to time entry in Agile Central that provides several interesting features.

• The timesheet can be set to have weeks that start on any day of the week. Caution: time is still saved using traditional AC time entry items, so if a week starts on a day other than Sunday, it will need to create a time entry item for each possible week that has a time entry value. This will mean that clearing the week will sometimes not remove the time entry item line -- it has to hold a spot for the previous week's data.

• The timesheet allows a user to set one or more time entry items as default. Then, when the Add My Tasks button is pushed, all of the default items are added to the time table. (Does not have to be a task to be pinned.)

• Different kinds of searches for things to add to the timesheet:

  • Add My Tasks looks for tasks the user owns and are in an iteration that overlaps the chosen week. (This is slightly different from the out-of-the-box button.)
  • • My (WorkProducts) looks for work products in a current iteration that the user either owns or owns a task for and just puts the story on the timesheet.
  • • (Tasks) opens a search dialog to find tasks directly using several search criteria including name and release.
  • • (WorkProducts) opens a search dialog to find workproducts directly using several search criteria.

• Filter for state: The administrator can configure the app to provide a filter that will allow for the restricted display of tasks by state. Filter choice does not affect stories/defects.

• The app can be configured to show different columns for different users.

• The app can be configured to allow for the entry of time in AC in chunks of time during the day.

• Shouldn't be able to remove a line if it doesn't start on monday and there is data from the week before (because we're faking a line when starting on a day other than Sunday to handle having two underlying Time Entry Items).

• includes a column picker for the non-required columns (can't hide day columns)

If you've just downloaded this from github and you want to do development, you're going to need to have these installed:

• node.js
• grunt-cli
• grunt-init

Since you're getting this from github, we assume you have the command line version of git also installed. If not, go get git.

If you have those three installed, just type this in the root directory here to get set up to develop:

npm install

• src/javascript: All the JS files saved here will be compiled into the target html file
• src/style: All of the stylesheets saved here will be compiled into the target html file
• test/fast: Fast jasmine tests go here. There should also be a helper file that is loaded first for creating mocks and doing other shortcuts (fastHelper.js) Tests should be in a file named -spec.js
• test/slow: Slow jasmine tests go here. There should also be a helper file that is loaded first for creating mocks and doing other shortcuts (slowHelper.js) Tests should be in a file named -spec.js
• templates: This is where templates that are used to create the production and debug html files live. The advantage of using these templates is that you can configure the behavior of the html around the JS.
• config.json: This file contains the configuration settings necessary to create the debug and production html files.
• package.json: This file lists the dependencies for grunt
• auth.json: This file should NOT be checked in. Create this to create a debug version of the app, to run the slow test specs and/or to use grunt to install the app in your test environment. It should look like: { "username":"[email protected]", "password":"secret", "server": "https://rally1.rallydev.com" }

Use grunt debug to create the debug html file. You only need to run this when you have added new files to the src directories.

Use grunt build to create the production html file. We still have to copy the html file to a panel to test.

Use grunt test-fast to run the Jasmine tests in the fast directory. Typically, the tests in the fast directory are more pure unit tests and do not need to connect to Rally.

Use grunt test-slow to run the Jasmine tests in the slow directory. Typically, the tests in the slow directory are more like integration tests in that they require connecting to Rally and interacting with data.

Use grunt deploy to build the deploy file and then install it into a new page/app in Rally. It will create the page on the Home tab and then add a custom html app to the page. The page will be named using the "name" key in the config.json file (with an asterisk prepended).

To use this task, you must create an auth.json file that contains the following keys: { "username": "[email protected]", "password": "fredfredfred", "server": "https://us1.rallydev.com" }

(Use your username and password, of course.) NOTE: not sure why yet, but this task does not work against the demo environments. Also, .gitignore is configured so that this file does not get committed. Do not commit this file with a password in it!

When the first install is complete, the script will add the ObjectIDs of the page and panel to the auth.json file, so that it looks like this:

{ "username": "[email protected]", "password": "fredfredfred", "server": "https://us1.rallydev.com", "pageOid": "52339218186", "panelOid": 52339218188 }

On subsequent installs, the script will write to this same page/app. Remove the pageOid and panelOid lines to install in a new place. CAUTION: Currently, error checking is not enabled, so it will fail silently.

Run this to watch files (js and css). When a file is saved, the task will automatically build and deploy as shown in the deploy section above.