The updated EmailImport Addon is now available for download from the GTD-PHP Trac wiki.

I have since moved on to the next most important feature on my personal list of Enhancements (yes, before I fix my known bug in the previous one). I want to be able to have a scheduled email sent every morning with a report on what Actions are overdue, what actions are due today and a rundown on the coming actions in the next week. Additionally this report should contain information on Project deadlines of note (overdue, due and coming). Another report I want is to be able to have the weekly review report emailed weekly to myself (at my work and home email addresses).

To achieve this I have been looking in to using php scripts to create cron jobs on the host system (or schtasks jobs if on a WAMP server for example). I have most of the information required to achieve this now. Once I have implemented a scheduled tasks manager from within GTD-PHP I will then build a custom report builder, which will then be enhanced by the emailer. In all, three addons become interlocked for completing this next feature.

If I didn’t have GTD-PHP (and therefore wasn’t following the GTD methodology) to manage all my projects I probably would not be in the position of even being capable of extending any project (I am busier now than ever, but I have more control over my time than ever before). By completing the Addons in my list I will have so much better control over my time and be in a perfect position to achieve some Zen in my life .

Just so you get some perspective, when I first set up GTD-PHP I added a lot of actions, and immediately closed them. Those statistics had me max at about 30 items in a week. Currently this week I have closed 75 items, and the week isn’t over. Most of these items have been self imposed actions for me to develop, research, repair, investigate, or whatever. I have given myself more work than at the start, and I have more time off now to blog about it (yet another action) than I have ever had previously.

I thoroughly encourage everybody to look into David Allens Getting Things Done. Worked wonders for me

Cheers, Chris.

Trav and I have approached the Server team with an idea on distributing apps more effectively, relying mainly on network addresses of the PCs to correctly locate an application server. This brings up a few logistical hurdles.

1. The restructuring of our Applications such that we can point to a mapped network drive instead of relying on UNC paths.
2. The fact that some applications are released with site specific information. As we currently have to modify every new release of these apps to include that information, we should approach the issue from a more managable perspective.
3. The Implementation of Login Scripts to Base Drive Mapping on current Network Location instead of the Current Login or Workstation Context or Group (as this then provides a benefit of decreased WAN traffic for Mobile Computers and Distributed Applications).
4. The Politics of testing and gaining approval for implementing a new process into something that is seen as a working system. This is possibly the greatest hurdle to overcome in regards to the push for initiative.

At least with respect to point Number 4, Trav and I raised this with one of our counterparts in the Server Team, and although we were given some good reasons why some of the ideas we initially had could not go any further than the drawing board, he did provide some additional ideas on how to proceed to at least implement some positive change so that we can all manage our site specific apps (Point number 2) more effectively.

The thing we need to concentrate on first is going to be appropriating some hardware and then building an environment in which we can test some of our theories that are not being implemented. In the mean time I will start testing some of the ideas that the team has approved at this point.

Hopefully we can implement a ZfS Server that creates NALs under the District Container (as opposed to our site containers) which uses %DEST-APPS1% as X:\ instead of a UNC path, and use a Cluster Wide Login Script to appropriately map X:\.

One parting thought on another issue this could have on us, that the X:\ drive is not consistent around the state. From ZfS’s perspective, everything is all well, however there are a lot more things stored on the X:\ drive that are used constantly from a Technical perspective. This will possibly require some more training, or at least another drive mapping…

Until I start looking into DFS at least

In three weeks time we shall see what position I am in though, before too many things are set in stone.

Cheers, Chris.