Timesheet Notes (2006)

Thu Jul 25

• Bug Fixes
  • timesheet.php - round/floor problems in carryover (-100 minutes shown as -2.20)
  • timesheet.php - Thu + Fri carryovers not included in total
• Modifications
  • Rewritten (50% shorter) timesheet.php added. Included code to display supervisee CRSids.
  • Rewritten (70% shorter) mon.php added.
  • leaving.php added (lets user set leave dates and prepares an e-mail message)
• Comments
  • All line managers need to be in the Staff database
  • Menus don't scroll in Mozilla
  • Authorisation not dealt with! Nor is authentication
  • Although on timesheet.php it says that bold items can't be changed, I think they can be
  • Store leave requests AND/OR authorised leave?

Fri Jul 26

• Bug Fixes
  • edittechnician.php - some variables (e.g. CRSid) not passed through the form
• Modifications
  • various parts of the leave request, leave request tracking, and authorisation process done. authorizerequests.php, listleave.php and leave.php created.
• Comments
  • No way to remove a technician?

Mon Jul 29

• Modifications
  • Table added to specify who has 'office' powers, etc. userdata.sql added and tables.sql changed
• Comments
  • "the plan was that the real system should use Oracle and have access to existing tables in the main people database" (jmrm). "We don't currently have the ability to access Oracle from a PHP application on Unix (Windows yes, Unix no). It's technically possible, but there may be some effort (Michael's) needed to make it work." (pnt)
  • PIN authentication is sufficient (mjg17 producing a new version of PIN authentication by mid-September)
  • "It was meant to be the case [that office staff can change the data entered by the technicians], at least for changes made by supervisors, that the data subject would be notified, probably be email. This could/should also include changes made by the office." (jmrm)

Tue Jul 30

• Modifications
  • newoffice.php (to add a new office person) added, and newtechnician.php changed so that they're added to the UserStatus table. day.php produced - a generalisation of mon.php

Wed Jul 31

• Modifications
  • authorizerequests.php updated to list other relevant leave requests. searchleave.php added to search supervisee leave (by type, by supervisee, by date). timesheet.php and day.php changed so that "last week" and "next week" buttons work.

Thu Aug 1

• Comments
  • Also needed - "Interface to Oracle, existing tables in people database" (jmrm). Also line-management info etc "needs to be in tables which relate to the main people database, probably based on the concept of roles" (jmrm)
• Modifications
  • searchactivity.php created to query the amount of time taken on an activity between specified dates. Doesn't yet search.

Tue Aug 6

• Comments
  • Some operational issues need to be resolved.
    • Currently the timesheets are filled in a day at a time. When weeklylist.php is run, the previous week's information is processed into a weekly record. If the running of weeklylist.php is delayed by a week there's no way to update the records of the 'missed' week. Also a timesheet's carryover value isn't correct until weeklylist.php is run to process the previous week
    • There needs to be a review of which entries can be edited. At the moment many entries can't. Also the initial carryover value shown on the timesheet is the value stored in the previous week's carryover value. If an old timesheet entry is changed, the subsequent weeks' carryover values all need to be explicitly recalculated.
• Modifications
  • carryover now passed from one week to the next. Some values weren't being passed through the day.php form, and a 0 carryover was being treated as piece of missing information.

Thu Aug 8

• Comments
  • Whenever someone edits information which isn't theirs, perhaps the change of role should be logged?
• Modifications
  • admin.html made into admin.php. Some buttons (e.g. the one to the Admin functions) on the main timesheet.php page are now conditional on the role of the user.

Mon Aug 12

• Comments
  • WorkingWeek doesn't have a year field
• Modifications
  • Added "request_date DATE NOT NULL, authorised_date DATE NOT NULL, authoriser VARCHAR(8) NOT NULL" to the HolidayDetails table and associated code changed.
  • A "Weekly hours worked" button on the main timesheet page (running weeklyhoursworked.php) prompts the user to type in a start and end week then lists the hours worked and carryover during each week.

Thu Aug 15

• Comments
  • What does the "checked" flag do in WorkingWeek?
• Modifications
  • Added "year INTEGER(4) NOT NULL" to WorkingWeek. Some associated code changed (in particular when operations span years) and some features added (e.g. the ability to compile Weekly records for any chosen week)
  • Tidied up the front page a little

Mon Aug 19

• Summary of things I need to know
  • Should technicians be able to change any data that they've previously typed in? ["I think that we decided that this should only be possible on the day in question or more ideally the same day the data is entered" - jmrm]
  • What should happen when an office worker edits the data that a technician's typed in? Should the technician be mailed? Should a record be kept? ["Yes, and yes probably (though maybe less essentially), I think" - jmrm]
  • WorkingWeek is a bundle of information storing how much a techician has worked in any particular week. What is the checked field for? ["I'd imagine that it's for the supervisor to fill in. With the current paper based system, this is a side effect of them submitting it to the office. It's a useful check on accuracy and therefore worth tracking" - jmrm]
  • Staff has a daysLeaveLeft field. When is this updated - when the leave's authorized? ["It might be more useful if all leave (already taken, authorised, and requested) were taken into account. Then if some leave isn't authorised the value goes up again" - jmrm]
  • What kind of searches might technicians want to perform on their own data that has been input previously? ["My guess is that this isn't going to be a hugely used feature. Browsing is probably sufficient at least in version 1" - jmrm]
  • What kind of searches might line managers perform on all data entered by any/all supervisees? ["
    1. List all work of a given type (eg they find that more time than they expected is being used for counting widgets) optionally restricted to a given time interval or day of the week (eg is some activity more popular on Friday than on other days).
    2. List all leave inc outstanding leave requests - a special case of (i).
    3. Produce tables of time spend per technician per activity - essentially a summary of outputs of type (i).
    4. Anything else that turns out to be useful, ie the framework should allow additions reasonably easily.
    " -jmrm]
  • What kind of searches might office staff perform on any/all data in any/all laboratories? Maybe something like How many hours in total were spent on Teaching in weeks 28 to 32 inclusive? ["Yes. The main difference between managers and the office is that the former have a larger set over which to aggregate and more subsets to select or tabulate by." - jmrm]
    What kind of output is required? ["Lists and tabular summaries, I think. Plus maybe a file which could be uploaded into eg Excel" -jmrm]
  • What kind of searches might office staff perform on any/all activities?
  • There's a facility created for office staff to use labelled View weekly lists. It uses a file called weekresults.php but that file doesn't exist so I don't know what it's supposed to do. What should it do?
  • The Carryover allowance isn't yet used. When should it come into play?

Tue Aug 20

• Modifications
  • ["the pages should probably have a standard heading to give them a clear identity" - jmrm] timesheet_header.html and timesheet_footer.html created and used to give a more distinctive look.
  • ["When you press 'view last week' the page which is displayed looks very like the current week one. Would, I think, be worth having the dates for the week more prominently displayed (eg as a heading) than they are. " - jmrm] Done.
  • Technicians can only change the current week's data (could as easily make it the current day)
  • Time spent on activities can be searched by office staff according to activity code/group/type, and date. Technicians can be selected individually or according to line-manager/division/section/Lab. Output can be sorted by date, activity or technician. Sample output's below

    ---

    The following activities match the criteria (activity type Part 1 between 2002-1-21 and 2002-8-21)

    By	activity code	Hours	Date
    mj111	A	0:0	2002-04-15

    ---

Wed Aug 21

• Modifications
  • weekresults.php added. I'm unsure about what it should do. Currently it displays a week's activities by "Group" and "Type". Here's some sample Group output.

    ---

    Activity Group	Total Hours	Mon	Tue	Wed	Thu	Fri
    -	0:0	0:0	0:0	0:0	0:0	0:0
    Infrastructure	0:0	0:0	0:0	0:0	0:0	0:0
    Research	0:0	0:0	0:0	0:0	0:0	0:0
    Teaching	0:0	0:0	0:0	0:0	0:0	0:0

    ---

Thu Aug 22

• Comments
  • The role of the office staff is still unclear to me. As I understand it, on Monday an office worker will update the previous week's weekly records of all technicians. Until this is done, the current week's timesheet won't show the carry-over. At the moment there's no provision for any automated checking of data (except that hours spent on activities will match total hours) and no way for office staff to set the "checked" entry of a weekly record. How much of what they check can be checked automatically? And shouldn't a note be kept of who did the checking? Currently
    • a technician could forget to fill in a day (or a week). Missed days are counted as standard days but there'll be no activity data for those days. Should this be checked for automatically. Is it ok for technicians to leave activity data blank?
    • The carryoverAllowance is 5 hours by default. I assume that means a week's final carryover figure shouldn't be more 5 hours from the norm. This is a check that's easy to automate retrospectively. It's not so easy to advise the user during data entry.
• Modifications
  • documentation added, and help buttons added to pages.
  • Check made in "View weekly lists" to see whether the carryover allowance has been exceeded, and links added so that each technician's timesheet can be inspectd.

Fri Aug 23

• Comments
  • I've gone through the 4th year report again and have noticed some things I still need to do (the report implied that these things had already been done, but I haven't found the code yet) so I'd better finish these things off soon.
• Modifications
  • permissions.php created to deal with authorisation. This issue wasn't dealt with in the 4th year project. I've decided to try an approach that's easy to use and extend now that the code in permissions.php is written. The idea is that 2 variables will be available to pages: a login_id (the identity of the person running the program) and a subject_id (the subject of a query). 6 authorisations levels have been established to deal with operations that
    • are only possible if login_id = subject_id
    • office staff can do
    • are allowed if login_id and subject_id are in the same lab
    • are allowed if login_id is the line-manager of subject_id.
    • are allowed if login_id is a line-manager
    • anyone in the system is allowed to do.
    Each page of operations can have a read mode and a write mode that's a combination of these modes. It's assumed that people will be able to read/write data about themselves (when this isn't appropriate some method other that permissions will come into play).

    So for example, the day.php page where people fill in their timing information now has

      $read_mode= $office_mode+$line_manager_mode+$all_manager_mode;
      $write_mode=$office_mode+$line_manager_mode;
    

    set, and a call to check_permission($login_id, $subject_id, $read_or_write) consults the current value of these modes to determine whether an operation is possible.
  • Office staff now go straight to the admin page.

Mon Aug 26

• Modifications
  • Indication in timesheet as to whether flexitime possible
  • Timesheet shows whether leave is taken on shown days (but activity breakdown can still be filled in for such days - to be fixed)
  • Ability to reject a leave request added. Does 'NotAuth' in the database mean 'pending' or 'refused'?
  • 'View Weekly Records' now has more features (not sure how to do exactly what's in the 4th year report)
  • 'Weekly record compilation' now reports if a technician has no records for the week.

Tue Aug 27

• Comments A few more outstanding issues
  • When specifying holidays I've not asked the user to fill in the length (0.5 day, etc) but instead added am/pm to the start and end dates. Is this ok?
  • Should a report be kept of who generated the weekly records? should a record be kept of who 'checked' each record? Should I check that each record has been checked?
  • Currently leave requests are in one of 2 states 'NotAuth' and 'Auth' but I'd like to add a 'Pending' too, to denote requests on which a decision hasn't yet been made
  • If leave is OK'd, who enters it as such into the activity tables? should it be done automatically?
  • Should the ActivityWorkingWeek table be used?
  Things to do
  • React when data belonging to one person is changed by another
  • Have a common color scheme. Currently more pages are in pastel, but a few are in a moody olive/maroon. Perhaps there should be colorcoding according to role?
  • Add full authentication on the login page and full authorisation on all the other pages.
  • Check use of tables with AUTO_INCREMENTed requestNos
  • Check that .5 days of leave are accounted for
  Summary list of table changes
  • UserStatus table added to show user powers
  • Added "request_date DATE NOT NULL, authorised_date DATE NOT NULL, authoriser VARCHAR(8) NOT NULL" to the HolidayDetails table
  • Added "year INTEGER(4) NOT NULL, creation_date DATE NOT NULL, check_date DATE NOT NULL, checker VARCHAR(8) NOT NULL, current INTEGER(3) NOT NULL DEFAULT 0" to WorkingWeek
  • Added "current INTEGER(3) NOT NULL DEFAULT 0" to ActivityTimes
  Summary list of files
  • timesheet.php - front page
  • day.php - fill in tme/activity details
  • leaving.php - requests leave
  • searchleave.php - search leave requests
  • searchactivity.php - searches activity information
  • edittechnician.php - edit techician details
  • newtechnician.php - adds new techician details
  • authorizerequests.php - authorize requests
  • listleave.php - list leave requests
  • newoffice.php - adds a new office worker
  • weeklylist.php - generates weekly lists
  • admin.php - admin front page
  • weeklyhoursworked.php - shows hours worked each week
  • weekresults.php - analyses weekly data
  • permissions.php - deals with permissions
• Modifications
  • test1.php created (800 lines or so) - sets up some trial data for weeks 32-34 of 2002. Office staff "off1" and "off2". Line managers "lm1" (with technicians "tech1", "tech2"), "lm2" (with technicians "tech3", "tech4"), "lm3" (with technicians "tech5", "tech6"). "tech1", "tech5" and "tech6" have various holidays. "tech6" has the most activities. "tech1" underworks on Mondays. Some testing done using this data and some bugs fixed.
  • More authorisation work done - when an office worker or line-manager views a technician's timesheet, the user and subject identities are kept separate. Note that this isn't yet done in a secure way.
  • Added creation_date DATE NOT NULL, check_date DATE NOT NULL, checker VARCHAR(8) NOT NULL, current INTEGER(3) NOT NULL DEFAULT 0 to WorkingWeek (to aid logged modifications)
  • Added "current INTEGER(3) NOT NULL DEFAULT 0" to ActivityTimes (to aid logged modifications)

Thu Oct 17

• Location of code and database - The code is currently on the projj machine using mysql on projj. The department's main Oracle database is available using Oracle clients on awl. Moving the code to awl and converting the code to use Oracle shouldn't be problematic (though Oracle access from PHP hasn't been tested here yet).
• Database Integration - How much information is currently stored on users? Should information on who is a technician's line-manager/lab, etc be part of the main database?
• When timesheets are processed into weekly summaries, the system reports if no records exist for any user - but how are partial completions dealt with? [jmrm]
• Customisation - A common complaint about timesheet programs regards the number of options presented when categorising tasks. Perhaps there could be default settings for certain (sets of) users who would only ever use a few of the options.
• When a line manager lists the leave of supervisees it would be useful to be able to see the remaining leave entitlements of the supervisees.
• Specification queries/additions
  • Authentication will be PIN-based. Access will be only from within the department.
  • Various queries could be added - list of line-managers?
  • Technicians can change the data about themselves during the week of the data
  • There's last/next week navigation but no way to jump to any week.
  • When is the exceeding of Carryover allowance reported upon - when the technician exceeds it or when the week is checked? W
  • Currently missing days are counted as standard days and it's ok if activity data is left blank.
  • Perhaps there needs to be more navigational links on pages.
  • Timesheet shows whether leave is taken on shown days (but activity breakdown can still be filled in for such days - to be fixed)
  • Does 'NotAuth' in the database mean 'pending' or 'refused'?
  • When specifying holidays I've not asked the user to fill in the length (0.5 day, etc) but instead added am/pm to the start and end dates. Is this ok?
  • Should a report be kept of who generated the weekly records? should a record be kept of who 'checked' each record? Should I check that each record has been checked?
  • If leave is OK'd, who enters it as such into the activity tables? should it be done automatically?

Thu Oct 24

May 2006

Requirements Specification

Interface Specifications