Another train ride, some more coding… This is a bugfix release. The following has changed since 0.4:

• Changed the display of site names to (site name) from site name: to make a visual difference between project namespace, and site name

Hopefully, this will make it clearer that the site name isn’t a namespace, but a different wiki.

To download the extension, do so via the extension distributor on the extension’s page at mediawiki.org.

Share:

I was on the train for a long time yesterday, and got a chance to fix some bugs. This is a feature and bugfix release. The following has changed since 0.3:

• Added different site name support (when breadcrumbs are enabled on wiki farms, and they share the same cookie path)
• Added support for preferences
  • Users can enable/disable bread crumbs
  • Users can enable/disable the prepending of site name onto titles
  • Users can set the number of bread crumbs to display
• Delete cookies on log out
• Removed some global preferences (replaced with default user options)
• Fixed localization issue with namespaces
• Only output Javascript/CSS when using the Vector skin

The usual methods should be used to download. See the extension’s page on mediawiki.org for download options.

Share:

Related posts:

1. JSBreadCrumbs 0.5 released
2. New MediaWiki extension JSBreadCrumbs 0.1 released
3. JSBreadCrumbs 0.3 released

• Display wgTitle instead of wgPage to avoid url encoded titles
• Fix issue where wgJSBreadCrumbsMaxCrumbs + 1 number of bread crumbs were shown instead wgJSBreadCrumbsMaxCrumbs
• Strip empty title and url when it exists
• Change the output of the leading description to look like “Leading description:” instead of “Leading description ” + wgJSBreadCrumbsSeparator, to make it more clear that it isn’t part of the history.
• Change the character used to split and join in cookies to ‘|’ since it is illegal in urls and page titles, and therefore is guaranteed to work, unlike using the user overridable separator
• Make addResources in JSBreadCrumbs.hooks.php public and static to get rid of php warning
• Allow the separator character to be localized
• Add preceding string to the breadcrumbs to describe their purpose on initial page load

For more information, see the extension page.

Share:

Related posts:

1. New MediaWiki extension JSBreadCrumbs 0.1 released
2. JSBreadCrumbs 0.4 released
3. JSBreadCrumbs 0.5 released

The breadcrumbs can follow users across wikis in a wiki farm, if those wikis share the same domain. This is the default behavior, but can be changed. The other configurable options are the number of breadcrumbs shown, and the separator between the breadcrumbs.

Since this extension is simply Javascript and CSS, it can be added to your wiki as a gadget, if you use the Gadgets extension.

To get more information, or to download the extension, please see the extension’s page on mediawiki.org.

Share:

Related posts:

1. JSBreadCrumbs 0.3 released
2. JSBreadCrumbs 0.4 released
3. JSBreadCrumbs 0.5 released

• Fixed issue with single domains, and non-auto-authentication domains being non-operational due to security fix in 1.2b
• Fixed another issue with mail me a password not working properly

To download this version, please use the extension distributor (http://www.mediawiki.org/wiki/Special:ExtensionDistributor/LdapAuthentication), select “Development version (trunk)”, and click “Continue”.

Share:

Related posts:

1. LdapAuthentication 1.2b released – Security fix for register_globals users
2. JSBreadCrumbs 0.4 released
3. JSBreadCrumbs 0.5 released

The following has changed since 1.2a:

• Fixed issue with group synchronization and nested groups
• Added support for exclusion groups in addition to required groups
  • Configured via $wgLDAPExcludedGroups; syntax the same as $wgLDAPRequiredGroups
• Fixed check for returns with no entries
• Added memberOf support
• Added patch for getting user’s primary group when using memberOf
• Fixed group synchronization issue with memberOf support (patch by Teddy Reed)
• Fixed problem with usernames containing parenthesis
• Fixed warnings in PHP 5.2.10 when some entries weren’t returned
• Fixed issue with $wgLDAPGroupsPrevail
• Fixed issue with mail temporary password button when email me a password support was enabled
• Added support for non-standard ports
  • Configured via $wgLDAPPort – see options documentation
• Changed debug to output to a file
  • Configured via $wgDebugLogGroups["ldap"] – see options documentation
• Added support for modifying LDAP options when connecting
  • Configured via $wgLDAPOptions – see options documentation
• Added a security fix for register_globals users (seriously, turn register_globals off, if you have it on)

To download this version, please use the extension distributor, select “Development version (trunk)”, and click “Continue”.

Share:

Related posts:

1. LdapAuthentication 1.2c released
2. JSBreadCrumbs 0.4 released
3. Using the LDAP Authentication Plugin for MediaWiki – The Basics (Part 3)

I’ve looked over the table of content so far and it looks like it will be a fairly concise guide for people new to MediaWiki. I did notice something missing already though. None of my extensions are listed in: “Appendix A: The Best Extensions for MediaWiki”! Maybe that’s something coming in version 1.2.

Share:

Notice that this ticketing system’s functionality will mostly be based on the functionality of OneOrZero Helpdesk (now AIMS). This isn’t a endorsement of the OOZ software. In fact, I went through the trouble of implementing a system like this specifically to move away from OOZ. OOZ is quasi-open source, and is switching to a CMS model, which defeats the purpose of its simple helpdesk nature.

Get the software

The following software and extensions will be used for this:

1. MediaWiki
   1. ParserFunctions
   2. LiquidThreads
   3. DynamicSidebar
   4. Semantic MediaWiki (SMW)
      1. Semantic Forms (SF)
      2. Semantic Result Formats (SRF)
      3. Semantic Tasks (ST)
   5. Replace Text

Follow the installation instructions provided by MediaWiki and each extension.

Create the structure

Note that before we get too deep into this, that I have an implementation of this already ready to test, and easily export. So, if you don’t want to go through the pain of creating all of the properties, templates, and forms, just get them from my prototype wiki. I’ll have instructions to do so at the end of this article.

Create properties

This will define the basics of your ticket. What information do you want to gather from the end-user? Use Special:CreateProperty for this (“Create a property” on Special:SpecialPages). Here’s a quick list to start you off:

• Supporter group – String
• Supporter – Page
• Priority – String; add a list of priorities here, I recommend:
  • Critical
  • High
  • Medium
  • Low
• Status – String; add a list of statuses here, I recommend:
  • Unassigned
  • Open
  • In progress
  • Waiting for response
  • Closed
• First name – String
• Last name – String
• Username – String
• Building – String
• Room – String
• Phone number – String
• Short description – String
• Long description – Text
• Attachment – Page

Adding more properties, and modifying them later isn’t difficult, so don’t worry too much if you don’t get everything you need at first.

Create templates

Now that you have properties defined, you’ll want a way to programatically fill them with values, and to display them. Semantic Forms has a special page to create a template from a list of properties. We should use this to create the templates. Go to Special:CreateTemplate, which can be found in special pages as “Create a template”.

Create the Ticket template

1. Enter “Ticket” for the template name (without the quotes)
2. Enter “Tickets” for the category name (without the quotes)
3. Add your fields from the properties previously created
   1. I recommend making the “Field name” and the “Display name” of each property the same as the property itself. So, for “First name”, “Field name” would be “First name”, and “Display name” would also be “First name”. Make sure to select “This field can hold a list of values, separated by commas” for fields that should be allowed to have multiple values. In this example, we are going to ensure “Supporter group”, “Supporter”, and “Username” allow multiple values, at minimum
4. Use “Standard” as the output format, and click “Save”; you can tweak the output format heavily later
5. Edit the template, and change the following portions, to add ST support:
   1. Change the “Supporter group” arraymap to: {{#arraymap:{{{Supporter group|}}}|,|x|[[Supporter group::x]] [[Assigned to group::x| ]]}}
   2. Change the “Supporter” arraymap to: {{#arraymap:{{{Supporter|}}}|,|x|[[Supporter::User:x|x]] [[Assigned to::User:x| ]]}} {{#if:{{{Supporter|}}}|([[Special:EmailUser/{{{Supporter|}}}|email]])|}}
   3. Change the “Username” arraymap to: {{#arraymap:{{{User name|}}}|,|x|[[Username::User:x|x]] {{#if:x|([[Special:EmailUser/x|email]])|}} [[Carbon copy::User:x| ]]}}

Create the User template

In this helpdesk system, we want users to be able to mark themselves as supporters, and provide some information about themselves. Since this is a wiki, we are assuming it is fairly open. If you want this to be locked down, you’ll have to find another method to go about this; notice, that this is possible, I just won’t go into it.

1. Enter “User” for the template name (without the quotes)
2. Leave the category name blank
3. Add fields for first name, last name, phone number, building, and room
4. Use “Standard” as the output format, and click “Save”; you can tweak the output format later (I like using actual infoboxes here)
5. Edit the template; at the end of your template, add: {{#ifeq:{{{Supporter|}}}|Yes|[[Category:Supporters]]|}}
   1. This will allow us to conditionally add people to the Supporters category

Create the Supporter group template

Unfortunately, SMW doesn’t allow you to query user pages based on MediaWiki user groups. So, we’ll make supporter groups based on SMW properties. We’ll want to have support groups that can hold a list of supporters.

1. Enter “Supporter group” for the template name (without the quotes)
2. Enter “Supporter groups” for the category name (without the quotes)
3. Add the Supporter property; make sure to select “This field can hold a list of values, separated by commas”, as groups should be allowed to have multiple supporters
4. Use “Standard” as the output format, and click “Save”. It really doesn’t matter what these look like; this is only used to add/remove supporters to/from groups

Create forms

Now that we have a way to programatically fill SMW values, and display them, we’ll want to make something for users to easily enter tickets. SF has a special page to create forms, based off of templates. To create the Ticket form, visit Special:CreateForm, which can be found in special pages as “Create a template”.

Create the Ticket form

1. Type “Ticket” for the Form name (without the quotes)
2. Select “Ticket” from the Add template drop down; click “Add”
3. Select Mandatory for whichever fields should be mandatory, and click “Save page”

Create the User form

1. Type “User” for the Form name (without the quotes)
2. Select “User” from the Add template drop down; click “Add”
3. Select Mandatory for whichever fields should be mandatory, and click “Save page”
4. Make sure the Input type for the Supporter field is set as checkbox; we aren’t setting a supporter here, but instead a true/false value that will decide if they are in the supporters category or not

Create the Supporter group form

1. Type “Supporter group” for the Form name (without the quotes)
2. Select “Supporter group” from the Add template drop down; click “Add”
3. Select Mandatory for the Supporter field, and click “Save page”
4. Edit the form, and change the supporter field to: {{{field|Supporter|input type=checkboxes|values from category=Supporters}}}

Create the Supporter groups

Creating supporter groups allows you to send ticket creation emails to entire groups of users, and allows users to get a view of only the tickets that pertain to their role. To create a supporter group:

1. Visit Form:Supporter group
2. Type the name of the group you wish to add into the inputbox, and click “Create or edit”
3. Select the users you wish to add, and click “Save page”

Create your navigation

Obviously, to test any navigation, you’ll want to add some test tickets first. So, do that before starting this.

Create basic sidebar navigation

For the basic sidebar navigation, you’ll want anonymous users to be able to view all open tickets, and all recently closed tickets. To add the basic navigation do the following:

1. Visit Special:Ask
   1. Create your query using your own username in the query, and test it
   2. Hide the query
   3. Copy the URL
2. Add the link to MediaWiki:Sidebar

Create sidebar navigation based on groups

Logged-in users need to be able to create tickets, view/edit their open tickets, and view/edit their recently closed tickets. It is easy enough to query per user for tickets in Special:Ask; the problem is that MediaWiki has no way, except via Javascript, to have content display differently per user. To add the group based navigation do the following:

1. Visit Special:Ask
   1. Create your query using your own username in the query, and test it
   2. Hide the query
   3. Copy the URL
2. Add the link to MediaWiki:Sidebar/Group:user. Make sure you add a new section, and add the link under that section. Also, make sure that “user” in “Group:user” is lowercase. “User” won’t work.
3. Modify the link to change your username to USERNAME
4. Add Javascript to MediaWiki:Common.js to change USERNAME to wgUsername

Create sidebar navigation based on categories

Users who add themselves to the supporters category, and support groups, will need to be able to view/edit their groups’ open and recently closed tickets. Like the user group sidebar, we’ll also need to change USERNAME to wgUsername, but the already created Javascript should handle that. Something extra we’ll need in this query, is a list of supporter groups to which the user belongs. We’ll need to use this list inside of our query. Thankfully, since we added supporter group pages, that have supporters as properties, we can get this list using a subquery. To add the category based navigation, do the following:

1. Visit Special:Ask
   1. Create your query using your own username in the query, and test it
      1. Your query should look somewhat like this: [[Category:Tickets]][[Supporter group::<q>[[Supporter::Ryan Lane]][[Category::Supporter groups]]</q>]][[Status::!Closed]]
   2. Hide the query
   3. Copy the URL
2. Add the link to MediaWiki:Sidebar/Category:Supporters; make sure you add a new section, and add the link under that section
3. Modify the link to change your username to USERNAME

Add statistics

I won’t go into too much detail here, since everyone has their own idea of what their statistics need to be. I have an example stats page to check out. You can use this as a base to get started. Notice that the example statistics page would be very inefficient for a large amount of tickets. I’ve tested it with 35,000 tickets, and it took nearly a minute and a half to load. I recommend breaking the page up, and possibly doing it more efficiently than I am.

Statistics look better with charts. I don’t have plotting support added in this prototype, yet; however, I plan on using my Plotters extension to take care of that. If you’d like to help out with the Plotters extension with Javascript, or PHP coding, I’d be more than appreciative.

Optional configuration

Optionally, you can move tickets into their own namespace, if you want them to be separate from the rest of your content. This is likely a good idea if you use your wiki as a documentation system. Remember, though, if you do this, to add the namespace to $smwgNamespacesWithSemanticLinks.

Missing features

• No supporter only comments.
• No separate forms for supporters and end-users; though, with a little extra effort, this is doable with some Javascript and/or multiple ticket forms.
• The long description field is not searchable via the advanced search form, or via ask queries, as text properties can’t be searched via ask.

Gotchas and workarounds

• Fields accept wiki text, and not all wiki-text will work in your fields. In fact, some of it will cause that field not to display, and will cause it to be ignored by SMW.
  • A workaround is to add the text to the page twice; once as a pre tag, that displays the text, and another, adds the property via a {{#set:<property>=<value>}} call. For example: {{#set:Long description={{{Long description|}}}}} {{#tag:pre|{{{Long description|}}}|style=”white-space: pre-wrap; white-space: -moz-pre-wrap; word-wrap: break-word; border-style: none; background-color: white; padding: 0px; white-space: normal;”}}
  • This workaround doesn’t solve the problem for SMW. Some tickets simply won’t have values for bad text.
• Ask queries are case sensitive. For properties that have a list of values, this isn’t too much of an issue, but for fields like “Short description”, this makes searches difficult.
  • A workaround for this is to lowercase values in properties, like: [[Short description::{{lc:{{{Short description|}}}}}]]
• Semantic Forms currently has a bug (verified in 1.9 and below) that will not read text that has been entered, and will cause properties to appear empty. Known problematic characters are {, | and }
  • A workaround for this is to add Javascript that will encode {, | and } characters on form save, and decode them on form load – this will cause problems inside of pre blocks.
  • The Semantic Forms author is aware of the bug. We’ve discussed possible solutions, but no code changes have occurred.

Exporting the system from my prototype

As mentioned at the beginning of this article, you can export the system I already have implemented, to save some work. Export the following categories and pages to get the system:

• Category:Ticket properties
• Category:Helpdesk interface
• MediaWiki:Sidebar
• MediaWiki:Sidebar/Category:Supporters
• MediaWiki:Sidebar/Group:user
• Template:Infobox

You will also want to manually copy the Javascript I’m using from MediaWiki:Common.js, and add it to your Javascript in MediaWiki:Common.js. Notice that you don’t necessarily want to export the category pages, but instead you want to export the pages in the categories. Special:Export has a field to do this. Also, my prototype wiki has tickets kept in a separate namespace. You’ll need to make some minor changes to the exported pages after importing them, if you don’t want tickets in a separate namespace. When exporting, ensure you have “Include templates” checked.

TODO

This is mostly a first-take at a system like this; the following things could be done to improve it:

1. Auto-populate the fields in the ticket with information from the user’s properties when creating tickets
2. Make the sidebar Javascript more generic
3. Update ST to have email templates, so that users don’t have to see confusing wiki-text in task assigned/created and diff emails
4. Update SMW to add properties to user pages for MediaWiki groups
5. Update SMW to allow Text fields to be searchable via ask
6. Update SMW to allow case insensitive searches in ask
7. Update LiquidThreads to allow transcludable discussions, so that they can be shown below ticket information on the ticket page

If you’d like to help, I’ll give you access to modify the prototype wiki. Coordination on changes ahead of time is preferred.

Share:

Related posts:

1. Helpdesk system and datacenter inventory Semantic MediaWiki prototypes added to my prototype wiki

Helpdesk system prototype

I’ve made a fully functional helpdesk application using Semantic MediaWiki (SMW), Semantic Forms (SF), Semantic Tasks (ST), Semantic Result Formats (SRF), Parser Functions, and Dynamic Sidebar. As an anonymous user, you can search, and view tickets; as a logged-in user, you can create tickets, and act as a supporter. The helpdesk also supports supporter groups, which are used for email notification, and for getting lists of tickets pertaining to your group.

Test it out in the prototype (OpenID is supported). Instructions for making yourself a supporter, and adding yourself to a supporter group are on the main page. The get emails, set your email address and confirm it via preferences. Notice that mail from my server may end up in your spam folder.

If you’d like to modify the helpdesk, you can in the sandbox. I wipe out the sandbox weekly, and re-sync it with the prototype.

In a future blog post I’ll explain how to create a system like this.

Datacenter inventory system prototype

I’ve added a form and template to track server information like IPs, MACs, OS type, OS version, Hardware information, etc. This information can then be queried and displayed. Here’s a few examples of how this can be really useful:

1. You have a virtual infrastructure, with a shared storage backend. You are doing thin disk provisioning to save storage space. As you are adding virtual machines, you are allocating OS space to them that isn’t necessarily being used on the storage space. It is possible to overallocate your storage; if you overallocate the storage too much, it is possible your VMs will start to fill up their allocated space, and eventually exhaust all available shared storage, killing all your VMs. With this inventory system, you can track how much space is allocated to each VM, then write a query to sum the total allocated storage space for all of your VMs. Doing so can give you an immediate view of how much storage you have allocated versus how much you have available. See the servers category for an example of this.
2. You need to keep track of who is assigned to admin which systems, to ensure that all systems are covered and all systems have backup admins. With this inventory system, you can assign wiki users as admins to systems. This information can be queried, so if you have an employee leaving, you know which systems need to be reassigned.
3. You have contractors who need to have a list of systems they manage. Since you can assign admins to systems, you can put a query on that admin’s user page that shows the admin’s list of systems. See my user page for an example.
4. You use static IP addresses on your network, and want to keep an IP database. Notice in this situation, you’d also need more forms, which I’ll be adding later, for things like KVMs, switches, etc.
5. You want to keep a MAC address database. Similar issues with the IP address database apply here.
6. You want to keep track of server types, and number of types of servers on your network. This can be useful for server consolidation efforts.
7. You want to keep track of which systems are in which racks, in which slots, which type of power they are using, and how many power supplies they have. Later I’ll be adding a rack form to keep track of information about racks in a datacenter. On rack pages you could use a query to display all systems in the rack, and which slots they are in. You can order the query to show systems from top to bottom order. If you integrate this with the Plotters extension, you could draw an interactive physical representation of the rack using Javascript and canvas.
8. You want to keep track of what type of hardware you are using in your datacenter. This can be useful for consolidating and standardizing hardware.
9. You want to keep track of which and how many operating systems are being used in your datacenter. This can be useful for consolidating and standardizing OS types.

Linking the two prototypes

These systems become even more useful when you start linking them. I will start adding some links soon for things like:

1. Per system and aggregated changelogs. A simple query can give you the changelog from all servers, if changelog entries are per system.
2. Per system and aggregated task lists. Since admins are linked with servers, you can even get per admin task lists.
3. Patch tracking.
4. Per system and aggregated change requests.
5. Maintenance scheduling. Thanks to SMW, and SRF output formats, you can have a maintenance calendar, a timeline view of maintenance, and export iCals so that users can add the maintenance schedules to their own calendars.

Future prototypes will likely integrate further into these prototypes. An end goal of these prototypes may be an enterprise architecture management system.

Share:

Related posts:

1. Creating a simple ticketing system with Semantic MediaWiki

I’ve taken some of the knowledge I’ve learned from working as a consultant for the Wikimedia Foundation to set my wikis up like a farm so that I can quickly add and remove sandboxes for targeted demos. I’ll write up some later blog posts explaining how you can set up a wiki farm.

Share:

Related posts:

1. Must have and promising extensions for a corporate MediaWiki instance
2. New MediaWiki extension JSBreadCrumbs 0.1 released