Storing shift patterns

Maybe I have thinking about it all wrong, maybe the database should store all the shift patterns for a year (365(6) * 3). For each shift pattern it could store which drivers are on duty. This information could be search to build up a list of shifts the driver is working. This could also speed up the search for who is available within a particular shift.

Date: 23/04/2008
ShiftNumber: 3
CommaSeparatedListOfDrivers: 24,01,06,22,14,15

Something like that would probably work. Otherwise I guess each driver would need to hold this information separately.

...?

Back to the blog

I am still waiting to hear back from my tutor regarding my first TMA. I have used the time to reflect more on the structure of the program with the realisation that some parts are harder than I expected.

My biggest issue is with regards to the program checking if a booking can be entered or not. My solution involves dividing a day into 3 time slots which correspond to the drivers shift patterns, a driver can work zero, one or two shifts in a day in any combination.

Each shift is then divided into 5 minute slots. A booking needs to consist of a time and length. When a booking is made the program will check

1. Which drivers are working the shift the time slot falls into.
2. For each driver
3. Get the drivers last booking prior to this one, check the length of the booking.
4. Store the start time of this booking as firstSlot.
5. Store the start time of the drivers next available space postSlot.
6. If the driver has an unallocated slot or collection of slots of enough length from firstSlot to store this booking then enter add it to this drivers bookings and end.
7. If no spaces are found for this booking then return firstSlot and postSlot for the user to choose from.

My problem is that the drivers don't work regular hardcoded shift patterns, some shifts are regular and other like every fourth Sunday are irregular. How do I code this and store this information? I still haven't figured this out yet.

A driver may occasionally be away on holiday or for one shift. This can be stored as a list of dates/shifts and this will be checked first before assuming a driver is available for this shift.

On a different subject user logon.

1. The client application will prompt the user for a username and password.
2. This will be Base64 encoded for HTTP transmission to the server.
3. The server will check that the username and password are valid.
4. The server will then respond with the access permission for that client, or username/password wrong.
5. If the permissions are returned then the client will configure itself to the user. If not it will keep prompting for username and password.
6. Optional - the server could respond with a timeout, once this passes the client will log the user out.
7. If the client has successfully authenticated it will keep the username and password handy for future transmissions.
8. Optional - In real application transmission would need to be over https in order to protect the username password combination.

The drivers holiday could be lower priority to implement since the idea is a proof of concept.

Securing a REST application

Due to the fact that this is not an open API for an open web service I need to think about securing the URLs. Each user will have a different level of access, a booker shouldn't be able to delete drivers or account customers. This could be set with regard to the URLs a client application can send. However there is the risk that if the API is accessible over the Internet which it would be for account customers that someone could attempt to access private information. For example a URL of drivers/32 could return the full details of a driver, name address, phone numbers etc. Someone who could guess the URL could type it into a web browser and gain access to information that should not be shared.

This comes back to logging into the system, if a user is not logged in then the server should return a 401 status 'Unauthorized'. If a user is logged in but doesn't have the correct level of status, for example an account customer trying to delete a driver then they should get a 405 status 'Method Not Allowed' and then the list of methods applicable to them GET, HEAD should be returned.