What's New in MainBoss 4.0
MainBoss 4.0 is a major update, including many significant new features. The following list outlines the differences between this update and the previous release.
MainBoss 4.0 will not run under Windows XP, Windows Server 2003, and earlier releases of Windows. It will only run on Windows Vista or later (e.g. Windows 7, 8 or 10), including the Server versions associated with those releases.
As an example of customizing table viewers, suppose your organization manages several different properties, and each property has its own maintenance supervisor. If you're the supervisor of a property, you could set up the Units table viewer so that it only showed units in your property; these settings could be given a name like "My Property". You could then tell MainBoss that from this point on, you want these to be your default settings—the Units table viewer would always be restricted to your property alone. Similarly, you could restrict the Work Orders table viewer so that it only showed work orders for units in the property you care about.
A table viewer may have multiple customizations available, with each customization identified by a name. For example, suppose you're a supervisor in charge of two properties, A and B. You could set up the Units table with settings named "A", "B" and "A&B". That way, you could quickly switch between seeing just the units in A, just the units in B, or the units in both properties together.
For example, suppose you want to look at all work orders created after a certain date. You'd go to the Filters section in the appropriate report window and you'd click the drop-down box's arrow. From the list, you'd choose to filter on Created Date. Once you specify this field, MainBoss will open another drop-down box with options like "is on or after" and "is in the range". Once you select "is on or after", MainBoss will open a calendar for you to specify the date you want. You'll then see a line with "Created Date" "is on or after" the date you choose.
When you specify a filter, MainBoss opens a new drop-down box below it. You can use this drop-down box to specify another filter. You can specify as many filters as you need. To get rid of an existing filter, click the red X button beside the filter.
For example, suppose you write up a work order to do a specific job and then you decide you want to do that same job every month. You can use New Task from Work Order to create a task record containing the work order's description and other relevant fields. You can then use the new task to create unit maintenance plans that will schedule the job on a regular basis.
Assigning yourself to a request can be done using either the MainBoss web interface (Web Access/Web Request) or the Windows MainBoss program. On the web, authorized users can get a list of requests that currently have no one assigned to them. They can then click a "Self Assign" button to assign themselves to a selected request. In the Windows program, there is an Unassigned Requests table under Current User Assignment Status; again, authorized users can assign themselves to any of the unassigned requests.
When you assign yourself to a request, it is automatically put into the "In Progress" state if it wasn't already. From that point on, the request is just like one that was assigned to you by someone else. It is removed from the Unassigned Requests table and added to the list of requests assigned to you.
In order to assign yourself to a request, you need the RequestAssignSelf security role. You also have to be listed in the Request Assignees table.
There are similar features that allow you to assign yourself to a work order or to a purchase order, provided you have the WorkOrderAssignSelf or PurchaseOrderAssignSelf security role.
In addition, icons now appear on the title bars of windows. This means they will also appear on window tabs in the Windows task bar. If you have multiple MainBoss windows open, the icons should make it easier to distinguish which window is which when you look at the task bar.
When a request is linked to a work order, you often would like changes in the work order's state to affect the state of the request. For example, when you close a work order, you might want MainBoss to automatically close the request too.
MainBoss now makes it possible for you to specify such automatic changes. You do this by setting up rules saying, "If a request is in state A and it's linked to a work order that goes into state B, then automatically put the request into state C." So you could say, "If a request is In Progress and it's linked to a work order that gets closed, then automatically close the request too." As another example, you could say, "If a request is Closed and it's linked to a work order that changes to Open (i.e. the work order is reopened), then automatically change the request to In Progress" (i.e. reopen the request too).
You specify rules of this kind in "Close Preferences", found in the Defaults for Requests section of the Requests table viewer.
You can also use the mbutility program to update user-related and requestor-related information from Active Directory . This includes getting rid of users and/or requestors who are no longer in your Active Directory. This will be useful for organizations like educational institutions, where there may be large turnovers in your requestor base over time.
The Web Access module can draw on Active Directory information to validate requestor email addresses. In this way, appropriate requestor records can be created "on the fly" for anyone in your organization's Active Directory. You may never have to create requestor records in advance for people in your Active Directory; Web Access will automatically create appropriate requestor records if and when someone in your Active Directory tries to submit a request. By running mbutility occasionally, you can remove any requestors who are no longer in your Active Directory.
MainBoss provides the ability to control this automatic creation of requestors. In particular, you can specify "Accept" and "Reject" pattern strings. An "Accept" pattern tells MainBoss to accept all requestors whose email addresses match a particular pattern, while a "Reject" pattern string tells MainBoss to reject requests from requestors whose email addresses match a different pattern. For example, you might only accept email addresses within your own organization, or you might reject specific email addresses associated with people who have previously made unacceptable requests.