Thursday, 10 September 2015

Login system change

New login screen

I am currently finalising an update that will provide a unified login experience across all OpsCentre applications (except the drivers' remote). Currently OpsCentre and ReportCentre use one method of logging in (select from user list and type in a PIN) while CharterAdmin and Invoicing use another (type in a username and password). The new login screen will make the sign-on procedure the same for all applications, using a simple username and password setup.



Domain credentials option

Many of our customers use Microsoft's Active Directory so that each user needs only a single set of credentials to access all their various file shares and systems. The new OpsCentre login system will allow OpsCentre to become part of this, so that OpsCentre users will simply enter their normal domain credentials to access OpsCentre as well.
Please note: To connect OpsCentre to Active Directory requires Microsoft's Active Directory Federation Services. Please check with your IT support to see if you have this available on your network.




User-roles replace area/action passwords

Currently OpsCentre requires a bunch of passwords to restrict access a various area or perform a particular actions. This results in users who are allowed to perform a range of actions needing to remember a multitude of passwords (or worse, writing them down somewhere). With the new login system, these passwords have been superseded by User-roles that can be assigned to users by an administrator. Users then only need to log into OpsCentre, and all actions they are allowed to perform will be available to them.
As a backup, however, I will also leave in the password system for the time being, for those occasions when users need to perform an action they are not normally allowed to perform (ie: they haven't been assigned that role). In these scenarios, they can still be provided with the password in order to perform the required action.

Multi-server installations

For those clients that have multiple OpsCentre server installations, the new login system will make it easier to ensure that users have access to the right areas and actions across all OpsCentre servers –  all while using the one set of credentials.
As an example, clients that have an onsite training server will be able to give access to areas like "Leave" or "Duty Maker" to users that are learning to take on these roles. This can be done just for the training server, while still restricting their access on the production server.
Another example would be for clients who have different OpsCentre servers for different branches. Here certain users can be given access to a certain role on all servers in order to manage that area/task company-wide.

Availability

As mentioned above, I am still finalising the system, so we're at least a few of weeks away from deploying. I will also be staggering the client application updates one by one, so it's likely that at first only the main OpsCentre application will make use of the new login system.
For now though, I would like all clients who use Active Directory on their network, to give some thought to the following: would you like users to be able to use their existing domain credentials to access OpsCentre, or should each user be given a new set of credentials? Note that using existing domain credentials will require that your IT support install Active Directory Federation Services (if this has not already been done) and configure it so for OpsCentre. If you would like to explore this option, please get your IT support to contact me so that we can discuss it in more detail.

Friday, 13 March 2015

Import recurring trips into OpsCentre

Import from an excel spreadsheet

You can import recurring contracted trips into OpsCentre by populating the sample spreadsheet with your own data.


Each column represents an individual timetabled trip. The detail of a timetabled trip is split into 7 sections.

Service area number



This can also be known in the industry as a route number. It is generally related directly to the contract, but not always.

Journey Number and Signage

The signage is generally the information that drivers are required to set a vehicles signage up for a trip. If signage is required to change mid-trip, then this can be dealt with by splitting the timetabled trip over two or more columns, where all details are exactly the same except for different signage and the timing points that relate to them.


As for the journey number (also know as a trip id), that is available for where it is required by contract.

Driver duty number and vehicle blocking


It is often know prior to import, how all the timetabled trips will be put together into driver duties and vehicle blocks. If known, these can be entered here, which will speed the process of getting the work into the operational schedule.

Vehicle specifications



Use these settings to define the seating capacity required for the vehicle, as well as whether or not it is required to be a super-low-floor vehicle.

Days of operation


Here you define what days of the week the timetabled trip is going to run on.

Special days (Statutory holidays)


These rows should mirror the stat-groups set up for the contract in OpsCentre. You can add or remove row as required. There should be always at least one though. This is true even if a timetabled trip is to run 365 days a year.

Timing points


You can add as many rows as you require here.In this example there a four timetabled timing points as well as an extra one designed to allow the operator to relieve a driver if required. You can see that this has been used to split the third timetabled trip into two to allow for the driver change in OpsCentre.
You can also see that not all cells have been filled in with a time. For example, the first timetabled trip doesn't have a time for "Wellington Train Station". This is because this particular timetable dtrip is supposed to start at "Courtney Place". By leaving the first cell blank, the import process will not generate a timing point for that location.
Lastly, all times must be entered without any period (.) or colon (:) between the hours and minutes, and times in the next day should start from 2400. So for example a timing point a 1:30am the next day would be entered as 2530.

If you need any clarification on any of the sections or how to deal with some timetabled trips, please don't hesitate to get in touch with us.

Monday, 16 February 2015

System requirements changes

PowerShell 4.0

We announced earlier today that an update for Report.Centre is available that can generate reports from PowerShell. This is intended to run on your server and requires PowerShell 4.0. (The system requirements for PowerShell 4.0 can be found here.) It is my understanding that all current OpsCentre installations are running on Windows Server 2008 R2 or higher so I am not anticipating any complications, but if you believe you may have a problem, please feel free to contact me so we can discuss.
I have a sample script available that generates and emails a report. Let me know if you would like a copy, as well as some instructions on how the new PowerShell commands work.

Upcoming .Net framework requirements

All current OpsCentre installations are running on servers that have version 4.5 of the .Net framework installed. At the moment version 4.5 is only required on the server, but I am currently working on development that will require 4.5 on client machines as well. The system requirements for 4.5 can be found here, but the short of it is that we will eventually require Windows Vista SP2 as a minimum client OS.
Initially this change in requirements will only be necessary for those users that require Report.Centre but as we continue to develop and refresh our suite of applications, this requirement will spread. If you have any issues or concerns please feel free to contact me.

Google Analytics

I have recently added Google Analytics (GA) to the development version of Report.Centre. By doing so I hope to better understand end users by seeing how often and what reports they are actually generating. This hasn't been released yet, but I intend to do so in the very near future. No Personally Identifiable Information will be sent to Google Analytics. Though I won't be able to identify any user by name, I will be able to see what reports are generated and how long they took to run. The only part that will partially identify any user, is when a customised report is generated. From this I will be able to deduce which company the user works for.
It is currently my intent to roll Google Analytics out to all other application in the OpsCentre suite so I can see which features are being used and how often. This information will help guide future development. Once again, if you have any issues or concerns please feel free to contact me.

Reports now available in PowerShell

An update is now available to Report.Centre that allows reports to be generated from PowerShell. What does this mean? PowerShell is Microsoft's scripting language for Windows. With this update you could write a script that would generate a report and then automatically do things like:
  • print the report to a particular printer on your network
  • email the report
  • archive the report to a file server
Once you have your script the way you want it, you can then set it to run from your server as a scheduled task so that the whole process is automated.

Please note: Not all reports are currently available in PowerShell but I am working on this at the moment. In the mean time, if you would like to take advantage of this new feature, please get in touch and I can ensure your required reports are updated sooner rather than later.