Archive

intranet

I readily admit that I have a bit of a NIH problem. A lot of this is laziness (hey, it’s a lot of work to figure out how somebody’s code works) coupled with the fact that I write fast married to the dilemma of if I modify this program to meet our needs, what happens when we need to upgrade?

One place where I’ve really struggled with this is surrounding intranets. At Emory I built myStaffWeb specifically to handle situations like:

  1. Employee needs to submit timesheet.
  2. Timesheet needs to go to employee’s supervisor.
  3. If either of these tasks are late, emails need to be sent to the guilty party.
  4. The supervisor either approves the timesheet (sending it to HR) or rejects it (sending it back to the employee).

Workflows like this are pretty commonplace for intranet-y tasks. The problem is that most off the shelf portal systems can’t handle them. Drupal, Joomla/Mambo, the Nukes all have horizontally based roles (members, editors, admins, etc.), which work fine for ‘content’ based sites, but lacks the granularity needed for ‘doing business’.

I built something similar to myStaffWeb when I got to Tech to handle other, similar tasks (set GALILEO password, upload EAD finding aid, manage subject guides, etc.). For ‘custom’ type modules, such a system works well; I am able to build a new module quickly and based on user, group and role models set up workflows pretty easily.

The problem is that as staff want to use more commonplace web tools (wikis, blogs, simple web pages, file management), it gets more and more complicated to keep up. The ability to draw from a large development community to help make your knowledgebase (say) or FAQ makes life a lot easier (and allows you to spend time working on things that help your public rather than your staff).

There are, in fact, some portal/community CMSes that have both horizontal and vertical permissions (‘manager’ of this group), such as Plone and TikiWiki, so I had held out hope they would work for us.

TikiWiki eliminated itself pretty quickly, however. It’s got an interface that only an engineer could love, is painfully slow, and uses the Galaxia workflow engine. I’m sure Galaxia is powerful and all, but it’s horribly over engineered for the simple workflows I need. Besides, most of our workflows are repetitive: employee -> supervisor -> task manager, to have to build that workflow in Galaxia every time for every app seems overkill.

Plone seemed perfect in every way. Our sysadmin installed it for the library collaboration committee to experiment with and it appeared to solve our problems. Groups and roles within groups, blogs, wikis, content. It looked like it could handle our intranet and our public website. Assuming we committed to it.

With every intranet I’ve developed, I have always looked at Zope. It seems to hold so much promise in this arena, but somehow, every time, something horrible goes awry. Zope (and therefore Plone) is an unholy beast and one of its biggest problems is that when something goes wrong, because it’s so alien (it uses its own webserver, its own database engine, it uses python in its own special way) there’s no body of knowledge to rely on to get you out of trouble. Nothing you’ve learned by using apache for the last 9 years helps you debug a Zope server problem. There may be ways to access the ZODB directly, but it’s not like being able to open phpMyAdmin and fixing a field value. Everytime I’ve dabbled with Zope, something bad has happened and I haven’t been able to fix it. And that sticks with you.

We had one of those problems early on with Plone (the sysadmin ‘accidentally locked the keys in the car’, as I put it — a bad incompatibility with the Zope control panel and Plone’s CAS plugin), but we got around it, documented it, made a policy for plugins and forged ahead. Despite my reservations about Zope, I suggested we commit to using Plone for the intranet and the public web. I didn’t see any point in trying to maintain two CMS systems if Plone was going to work for the intranet.

And then we found Plone’s fatal flaw. While working on a wiki to document how to troubleshoot the Umlaut while I was in Toronto, something happened and somehow I saved a much earlier revision of my page (losing about half my work). Since I had been saving my edits, I assumed I could just rollback to a previous save, but you know what happens when you assume. To my (and the sysadmin’s) horror, we realized that Plone has no concept of versioning.

There are Plone products that deal with this, but none have ‘stable’ releases and, besides, depending on a product for such core functionality seems risky. When and if versioning is integrated into Plone core, will your product be compatible? Will you get stuck behind if a new version of Plone comes out and your particular product doesn’t work with it? This gaping hole in functionality (coupled with learning curve inherent in Plone to begin with) basically brought our Plone experiment to a grinding halt.

So last week I started redesigning the existing intranet. I’ve migrated it to rails, and yet again I’m amazed at how quickly I can get core functionality running. Ruby/Rails is so much better suited to object model in our intranet than PHP was it makes this tremendously easier. Rather than worry about building wikis and blogs and whatnot, we’re just using off the shelf products that are remotely editable. For wikis, we’re using OddMuse, for blogs we’re using WP-MU. This way, I only have to make clients in the intranet to access these remotely. In essence, the intranet aggregates services and manages permissions (this wiki is only available to the group or the user or to the library, etc.) and handles our specific needs, like timesheets and student employment applications and the like.

So basically we’re finding a compromise between invented here and there. Just in time for me to drop this project like a hot rock for a new position 🙂 (more on that later).