Add a listener (probably in the form of a cron job that runs every 15 mins) that checks if a user who is scheduled has clocked in yet. If their shift started 15 mins earlier and they have yet to clock in, email their supervisor that they have not yet clocked in. Do this every 15 minutes until the clock in.

Migrations are essential for updating schema on deployment when it changes in development.

See http://symfony.com/doc/current/bundles/DoctrineMigrationsBundle/index.html

Will likely be used to run on a cron job to clock out users at the globally set end hour.

Needed for issue #24.

Clock data needs to be moved weekly to an external data store (not the MySQL database) and stored for 4 months or so before it is pruned. The data should be stored by week and reports should be generated in a way where it compares clock data with schedule data, distinguishing between scheduled and worked, not scheduled and worked, scheduled and not worked, and not scheduled and not worked. Backend could be either SQLite, or maybe even MongoDB.

Garreth also asked for something along the lines of employee statistics. E.g. Rank employees by lateness, earliness, frequency of late clock in, etc. See issue #24.

Implement pagination on pages which list records of which their is no real limit to the number of items.

This will introduce some much needed scalability. Right now the index pages will fetch records until they have them all, PHP runs out of memory, or the request times out.

Embrace REST and implement an API which the application will consume, as opposed to an API that communicates with the application internally.

Helpful Resources:
http://williamdurand.fr/2012/08/02/rest-apis-with-symfony2-the-right-way/

In a few recent commits (0f86b3b, 03f6905) I resolved a bug where some users would not show up, even if they were available because of the existence of any schedules for a different position but this introduced another bug where users were shown multiple times in a time slot because the availability schedule was checked twice.

Because this is core functionality, it needs to be resolved before anything else.

Allow users to export their schedules to Google Calendar.

Used for the API.

Add controls for batch adding and deleting users. This will likely require more frontend development (jQuery or something) for adding table rows with fields for default data.

An application settings page should be added which stores a number of global application settings such as:

• IPs allowed to use time clock functionality
• Start/end hour for scheduling views
• Default time resolution
• Option to enable or disable notification emails by default.
• Branding name
• Branding icon

Implement assetic so resources can be managed by the bundle and compressed on delivery.

Supervisors should be able to schedule employees in the same manner as Employee Scheduler. This involves showing which users are available for a block of time (15 min, 30 min, and 1 hour resolutions) and allowing them to be checked to schedule. Users should be shown with their configured color as the background and their preference level for a specific time period alongside. Users should be scheduled based on position.

Due to the speed at which I work on OpenSkedge, the lack of other contributors, and the fact that I generally know my code like the back of my hand, I have failed to provide adequate commenting of my code. This makes the barrier to entry into OpenSkedge rather high as it takes fair amount of analysis of my code before what is being done is as clear as it is to me.

I will make an effort to add more documentation to the code from here on out. This issue will stay open until I have added function, parameter, and return value comments to all methods and go through some of the more difficult logic in some classes and thoroughly document what's going on.

Documentation needs to be written for installation, upgrading, and some basic project details. This can be pretty simple.

Along these lines:
0. Run php app/check.php and resolve any errors before doing ANYTHING else.

1. Give overview of configuration options that should be edited beforehand.
2. Run php composer.phar install or php composer.phar update depending on if installing or upgrading.
3. Run php app/console doctrine:database:create
4. Run php app/console doctrine:ensure-production-settings if running on a production server (NOT RECOMMENDED yet (except for CSOM ITSS))
5. Run php app/console doctrine:migrations:diff to diff the current database. Run php app/console doctrine:migrations:migrate to update database schema to current schema with mapping and everything.
6. Run php app/console doctrine:fixtures:load to bootstrap the application with some needed information (groups) and an admin user.
7. Navigate to OpenSkedge installation in a browser, login as the bootstrapped admin, CHANGE PASSWORD.

Users should be able to select a specific date and time period out of their scheduled shifts for a certain position and post if for someone else to pick up.

PHPUnit test cases need to be written for all the actions and API calls.

See http://symfony.com/doc/current/book/testing.html#functional-tests

I've been hearing a few comments from users who say they find it rather confusing to track which parts of navigation certain actions fall under. Breadcrumb navigation should be implemented to make this more clear and allow users to easily navigate backwards instead of starting over from one of the actions in the navigation sidebar.

OpenSkedge needs a logo and a favicon. Pretty low priority though.

Disk-based session storage is terribly slow and it's quite noticeable on the Pagoda Box instances. Sessions should be handled by memcached for speed. This also has the side effect of making OpenSkedge scale better in the rare instance where that is actually needed.

This module should display total hours scheduled, total hours requested, hours scheduled for each position, and number of times the user has been late.

This bug appears to be only appearing on my PagodaBox test instance. Certain queries are not returning any results.

Examples:
Dashboard doesn't show a schedule, even though one exists in my test instance for that schedule period.

'My Positions' returns zero positions even though the user is scheduled for two.

Time clocks should be backed up and reset on a new week.

How they should be packed up is a topic under consideration. A new MySQL table for each week is a terrible idea. A new SQLite database for each week is under consideration but caries file permission concerns. Backing up to a JSON files is under consideration, but has a number of issues including file permission concerns. MongoDB is being heavily considered but introduces some concerns about adding another dependency.

I've been told the 'Edit Position Schedule' button is a confusing way to get to scheduling positions and that the positions should be listed like how schedule periods are listed in the position view.

Fixtures will be needed to install default data into the the database in order to bootstrap the application.

http://symfony.com/doc/current/bundles/DoctrineFixturesBundle/index.html

Entity class should implement Symfony2 validation in the form of Assert annotations using Symfony\Component\Validator\Constraints as Assert.

See http://symfony.com/doc/current/book/validation.html for more information.

Allow admins to define a default start and end hour for schedules and availability schedules.

E.g. Employers who don't schedule before 7am or after 10pm shouldn't have 12am-6am or 10pm-11pm showing up in their schedule views.

See http://www.datatables.net/blog/Twitter_Bootstrap_2

When editing a user, if their password is left blank that becomes their password. Leaving the password field blank should leave their password unchanged. I implemented something I thought would work, but it's not working correctly.

Perhaps their original password (encrypted of course) should be stored in a hidden field that is used to compare the value of the password fields.

A dropdown should be added on the dashboard interface for selecting which of the current scheduling periods should be used for the schedule module on the dashboard.

The selected schedule period should trigger a GET form action adding the id of schedule period.

All the backend code has support for configurable time resolution where relevant, but it's currently set to "1 hour" by default. Time resolution controls should be available to the user and passable to parts of the backend that support it.

Prevent data pileup by allowing OpenSkedge to automatically remove time clock data that is older than a configured number of weeks in the past.

This will be used for serialization to JSON and XML for the API.

I'm not sure whether to put position schedule creation links on a schedule period's page or a position's page, or both.

A mailing service should be created which implements Swiftmailer and can be utilized to email users when their account is created, email supervisors when an employee posts their availability, and provide a form for supervisors to email all their employees.

Schedule editing views should keep track of hours added to an employee's schedule.

CRUD for AvailabilitySchedule needs to be remade using a method similar to Employee Scheduler where the user selects availability based on clicked table cells for each preference level. The old table view from Employee Scheduler should be reused as best as possible and should be made to work with the new data structure.

Move queries from Controller to the Repository classes of the entities they involve.

When a user deletes a schedule, their availability is deleted, but the position assignments remain, leaving orphan position assignments in the database that cannot be delete from any views as they do not show up in the positions window until availability is added for the schedule period.

I've only seen this happen on the Pagoda Box instances.

The basic CRUD scaffold has been generated. It needs to be fully implemented.

This should include viewing schedule periods as a list with start and end dates listed. Viewing a schedule period should reveal users scheduled/with availabilities for that schedule period. Creating a schedule period should be a simple form with a DateTime selector for start time and end time. Editing should be the same. Deleting should be a simple REST request only to be completed by supervisors.

Scrutinizer-CI flips shit with a few functions, notable ScheduleController:editAction().

When supervisor or admin is editing their own user profile, they show up in the supervisors list and can thus set themselves as their own supervisor. Doing so does not cause any errors or any other problems, and there is no real reason why someone would set themselves as their own supervisor.