Home
Contact Us
Site Map
Features & Benefits
Frequently asked questionsTechnical
Web browsers
Which web browsers do you support?
The following browsers are supported:
• Internet Explorer 7
• Firefox 2 and 3
• Safari 3.1
• Internet Explorer 6
Internet Explorer 6 (IE6) is supported (with recent Microsoft patches), but Internet Explorer 7, Firefox and Safari are the recommended browsers, as they are significantly faster than IE6.
Pre-release versions of browsers are not supported. TimeFiler is not presently available via mobile phone browsers, but we will continue to monitor this platform for future usage.
New versions of supported browsers are not supported until notified, however, we will quickly look to support new browser versions as they become available (for example, we already support Firefox 3 as soon as it is formally released). Note that providing support for new browser versions might require an upgrade to your TimeFiler system.
If a user accesses TimeFiler via an unsupported browser, a pop-up appears to notify them.
Internet Explorer 6
Many companies still use Internet Explorer 6 as the default web browser, and for this reason IE6 is supported for TimeFiler. However, IE6 has some drawbacks due to some well documented issues:
• IE6 is slower than Internet Explorer 7.
• IE6 has cosmetic layout and image differences due to its lack of support for recent browser features.
• IE6 uses more memory on the user's computer.
• TimeFiler and other rich functionality web applications offer the best experience accessed via more modern browsers.
- Are there any browser installs?
No. There are no downloads to the browser (other than normal servings of html/js/css).
- How should the user’s browser be configured?
A default installation of any supported browser is ideal for TimeFiler.
• Browsers must permit Javascript.
• Ideally, browsers should allow the server to generate pop-up windows.
Reports are presented in a pop-up window (if this is disabled, users will be informed and are presented with a clickable icon, allowing them to open the report window manually.)
Reports
- How do users run reports?
Web users can generate reports from most TimeFiler screens, significantly the leave planner and roster views. Reports can be output to Excel (native format), PDF or a browser window.
Web users can also select from designed reports as made available using TimeFiler Studio.
- How do we design reports?
TimeFiler Studio enables administrator users to build reports using a grid-based report builder interface, which saves the report in native SSRS format.
Users who wish to extend the report (such as to include data from third party databases, or to include additional report features) can simply save the report file from Studio into SSRS rdl format, and edit it in Visual Studio .NET or other SSRS report tools, before importing it back into TimeFiler Studio for users to access like any other TimeFiler report.
- What report engine does TimeFiler use?
TimeFiler uses Microsoft SQL Server Reporting Services (SSRS) to render reports. SSRS is a widely used, capable report writer and is available as part of the SQL Server license.
Microsoft limits some SSRS functionality in SQL Server 2005 Express Edition, which we have worked around to ensure that users get the same report functionality no matter what version of SQL server is in use.
- Why SSRS?
We required some key features for TimeFiler reports:
• No additional license cost for standalone clients.
• Simple user-interface to design reports.
• Option to extend reports using a designer that is widely accepted and utilised.
• Ability to respect the user’s TimeFiler security, without needing NT security.
• Ability to include data from third party databases.
• Ability to output in native Excel and PDF format, and a printable browser window.
• Ability to e-mail reports regardless of SQL Server model used.
• Close integration with TimeFiler web interface.
SSRS, with some careful development, enabled us to provide all of these features.
Find out more about our reporting strategy here.
- How are reports generated?
SSRS processes the report and renders it, but TimeFiler takes responsibility for capturing report parameters and respecting application security, and shows the report.
This has enabled us to more closely integrate TimeFiler and SSRS, and to overcome some of the known difficulties with using SSRS, such as support for page layout, non-Microsoft web-browsers, and to eliminate the need for a full SSRS report designer to build reports.
This makes the production of reports very straightforward, and in most cases means users do not actually require a standard SSRS report designer, but there is still the freedom to extend the report using Microsoft Visual Studio.NET.
Read more about our SSRS reporting strategy here.
- Can we show any SSRS report?
Yes*. TimeFiler can become a launch pad for all employee reports, and as TimeFiler knows about employee security, it can apply employee-based security automatically, without requiring NT authentication.
* Some SSRS features are not presently supported (such as drill down).
Architecture
- How does the TimeFiler back-end work?
TimeFiler revolves around Microsoft products. In particular, Microsoft Windows Server, Microsoft SQL Server, and Microsoft SQL Reporting Services.
The TimeFiler application server is a windows service listening to http/https ports of your choice. TimeFiler installs all under one directory, and does not write to the registry. Other than a couple of minor initialisation files to find the database, reporting and email server, all settings are stored in one Microsoft SQL server database with the rest of the company data.
TimeFiler communicates with Microsoft SQL Server, Microsoft SQL Server Reporting Services, and any SMTP server for e-mail reminders and administrator activity logs. It can synchronise with a variety of third party systems, including a very comprehensive synchronisation with other products that also use Microsoft SQL Server databases, for example your payroll or accounting system.
The application server serves html/js/css without going through a dedicated web server. TimeFiler is nearly 100% Ajax which means it is very interactive, yet completely web based. Other than some initial web related files served to the web browser (which are mostly cached once served), most of the traffic between the web browser and the application server are simple native Ajax messages.
The Javascript libraries we use are comprehensive enough that the web brower ends up with enough information to display and interact with rich functionality without having to continually go back to the server for basic GUI instructions. There are absolutely no downloads to the browser other than normal servings of html/js/css, and a variety of web browsers are supported.
- What versions and editions of Microsoft SQL Server do you support?
We support MSSQL 2005 and above. We also support all editions of SQL Server, for example:
• Express
• Workgroup
• Standard
• Enterprise
In terms of the Express version, just bear in mind the limitations of this edition of SQL server, but for small implementations, it is perfectly acceptable.
Additionally our handling of SQL Server Reporting Services (SSRS) means that some features not supported by the Express edition of SSRS can still be achieved within TimeFiler (for example, report emailing).
- Why don’t you use IIS rather than a Windows Service?
For most of the interaction with TimeFiler, a browser will be talking using very light Ajax/XML like messages, serving very little HTML, and caching all Javascript files. TimeFiler itself then ends up being mostly an application server doing timesheet processing and management. So it is capable of serving up HTML and Javascript, but this is mostly to supply the browser with enough beginning information to be able to talk to TimeFiler as a rich internet application.
We’ve made the call so far that IIS just isn’t necessary to also be part of this loop, and that it is much easier to most people administrating or installing TimeFiler to think about is as a normal Windows service. We may review this in future if there are strong views about this, and stand alone customers would prefer to have TimeFiler also hosted within IIS.
- I want to let TimeFiler be internet facing, but I don’t want to expose anything else to the internet including Microsoft SQL, and Microsoft SQL Reporting Services. Can this be done?
Yes you can. As was discussed in our reporting strategy section, TimeFiler shoulders a lot of the burden from SSRS. In particular an employee never has to directly interact with reports using SSRS. TimeFiler only calls SSRS when it needs to, and uses it mostly for a report generation mechanism which TimeFiler displays after it has finished. In other words, the employee’s web browser actually never goes directly to an SSRS server.
So you can quite happily have Microsoft SQL Server, and Microsoft SQL Server Reporting Services on the internal network, and TimeFiler on the DMZ. TimeFiler doesn’t even have to know about NT security, and can communicate with SSRS using basic authentication (this communication is strictly between two servers… the TimeFiler server on the DMZ, and the SSRS machine on the internal network, but can also use SSL here if needed).
- We want to have a link for TimeFiler on our intranet, is this possible?
Yes, this is quite normal, and it typically just a simple link. It is also possible to show TimeFiler within a frame of your intranet page (called an iframe).
- Can we change the look of TimeFiler to suit our own organisation, in terms of colours and our own logo?
Under our hosted solution, you definitely can do this. We are currently in the process of making sure that our standalone option has this capability as well.
Currently our ‘skinning’ solution only applies to the basic colours and logo in the web user interface. We are also considering allowing the skinning to flow into the reporting output as well.
Security
- Can TimeFiler respect our users' NT authentication?
Yes. TimeFiler will communicate with one of your IIS servers to check these credentials. If the IIS server is unavailable, the employee is still able to log in, but they will have to supply their TimeFiler password for their NT domain and username.
Because TimeFiler calls a page hosted on your IIS server, even where TimeFiler is hosted by us, it can still use NT authentication to log your users in.
- Can we use SSL?
Hosted clients: Yes. Our hosted service offers clients the option to use SSL for their TimeFiler system. Please contact TimeFiler Support to have this enabled (there is no charge for this service).
Standalone clients: Again no problem with SSL. We have detailed instructions on this, please contact us for more information.
- How do I backup my TimeFiler database?
Backups can be run from within TimeFiler. Alternatively you may wish to automate them on the SQL server itself using standard SQL Server concepts.
In a hosted situation, regular backups are occurring each night including backups on the same network, and offsite. You are also free to make backups at any time and download as a MSSQL server .bak file for extra peace of mind.
- Explain your application security model. And how does this tie in with your reporting framework?
TimeFiler has a work area based security model. Employees are attached to a work area, and there are manager(s) specified in each work area. An employee can manage more than one work area if necessary.
Additionally if you want the extra functionality, there is the ability to specify a hierarchy of work areas to reflect the organisational ‘tree’ in its entirety. This is what would allow a CEO to drill down several levels below their immediate reports if they wanted to.
To complete the security model, you are also able to optionally use date sensitive fields in TimeFiler to deal with employees changing work areas at different points in time as well as the manager(s) of each work area changing over time. This allows smoother transitions for changes, and loading those changes in advance.
So from this work area based security, any employee logging in will see only the employees they are allowed to see. And with the hierarchal side of work areas, we can make sure a manager can see either their immediate reports or others further down the chain if they want to look further.
This security model applies not just in timesheet/request entry, but everywhere including in reports. Even reports that source data outside of TimeFiler can be made to respect TimeFiler security. This means you only need to write one report rather than having lots of locked down reports for each manager.
Installation
- How do I install TimeFiler in-house?
We have detailed instructions, but there is nothing more onerous than installing a Windows service, and supplying connection information communicate with Microsoft SQL Server, SQL Reporting Services, and an SMTP server.
We also provide detailed instructions that allow TimeFiler to be locked down as securely as possible with respect to directory, database, and reporting security.
TimeFiler is usually configured in conjunction with a Time Management consultant as most customers are trying to squeeze as much complexity into TimeFiler and out of individual’s heads as is possible. This is understandably a skilled job to take this complexity, confirm and distill it, and shape it into TimeFiler in a way that will be maintainable in the years to come.
- What hardware configuration is recommended?
It depends on the size of customer, the number of employees and the complexity of the time management being achieved. This can vary considerably between customers.
For the handling of the Microsoft SQL Server database itself, TimeFiler is not particularly demanding on the SQL database server. Microsoft SQL Server Reporting Services can consume a lot of memory, and if this is taken away from applications like TimeFiler there can be some effect. So if the project justifies it, we’d like the TimeFiler application being separate from the database server, and reporting services.
The TimeFiler application itself is very interactive with client browsers. As employees input timesheets, TimeFiler will respond back with the calculated payments, and validation issues that have occurred. Usually customers will want to take full advantage of TimeFiler, and make it deal with as much complexity in the rules as they can throw at it. This means that we need to keep track of a huge amount of information for each TimeFiler session which makes it quite different from traditional web applications which tend to pride themselves on being able to handle thousands of sessions, but not handle the immediate complexities that TimeFiler needs to handle.
So TimeFiler will require a lot of memory for each session, and we don’t expect to ever have more than 150-200 sessions on each application server. This may not sound a lot, but this level of concurrent sessions will usually service an organisation of 2,000 employees. Because we want TimeFiler to be as useful as possible in helping employees deal with timesheeting and time management, employees are usually not in the system for long. This is exactly what everyone wants. But if you need higher service levels, then it is just a case of adding more boxes to serve the application.
For the TimeFiler application itself, we’d like to see as much memory and CPU as you can reasonably provide. So quad-core, 3GB memory is a good specification. HDD isn’t so important unless you are intending to host the database on the same machine as well, in which case all the standard database recommendations for SQL Server would apply.
- What security measures does TimeFiler have to protect my data?
TimeFiler stores all data in a SQL Server database, and passwords are internally encrypted. TimeFiler can communicate with the client’s browser using SSL if required.
We also provide detailed instructions that allow TimeFiler to be locked down as securely as possible with respect to directory, database, and reporting security rights.
We have a number of ways you can connect to both MS SQL Server and MS SQL Server Reporting Services depending on your requirements.
- If we decide to have TimeFiler hosted by you, will TimeFiler still integrate with my in-house payroll / accounting software?
Mostly, although there are restrictions. In terms of the interface files that TimeFiler will create, these can be easily downloaded from the hosted system and placed into the location that the payroll or accounting software expects.
The restrictions are mainly to do with full synchronisation with the vendor’s system. This is usually more difficult because both of our systems (ie your payroll system, and our hosted TimeFiler system) will be tightly locked down.
But we are happy to discuss and work through on a case by case basis. And as our hosted option becomes more popular, we may consider having a way of improving synchronisation from local systems.
 Pricing & billing |
Third party product integration  |
Try TimeFiler now
Enquire now