Date String Sorting Fun

Wow — this date string sorter is turning out to be a little bit more trouble than I thought. The actual logic isn’t all that hard (it’s about three arrays, one class, and some string functions) — I’ve just been picking over the little details for hours now!

Sorting Date Strings

As of this moment, I’m trying to get Domino date lists to sort out in a more intuitive fashion.

In the XML file that I’m accessing, the dates are ordered from most recent day to oldest day; however, the entries belonging to the times of each day are sorted with AM first (it appears to be sorted alphabetically — silly Domino). For example, a document with the date 07/25/06 will come before 07/24/06, but a document made at 10 a.m. on 07/25 will come before one made at 3 p.m. on that same day.

Well, this certainly cannot be! If anybody knows of a way to get Domino to do this automatically, feel free to comment. (And if you’ve found this blog so soon after I started it, thanks for posting!)

Right now I’m just taking the document dates, putting them into arrays and string lists, and parsing the hell out of them until they’re ordered right. Fun stuff.

Auditing Explained

Okay, let me explain a little bit about what I’ve been doing. I’ve been instructed to produce “auditing” scripts on a database application that has been assigned to me — basically, a series of scripts that will keep track of changes made by users in documents of the application.

Not so hard, eh?

I wish. Making an actual script like this work is no big deal, of course — making it secure, however, is.

This application is going to be web-based, so that means that the bulk of my programming is going to be done in JavaScript — although, as I’m sure you know, as far as security is concerned, JavaScript has very, very little. The entire nature of a client-based scripting language like JavaScript pretty much negates the idea of security entirely — you see, the user has access to everything, and, well, what’s stopping them from changing something stored on their own computer, hmm? Nothing.

So, I’ve had to learn the server-side scripting language necessary for this to work, and on a Domino server that means LotusScript. And of course, to utilize LotusScript in a web application, you have to make use of the “WebQueryOpen” and “WebQuerySave” server events.

I combined these two technologies together into one pretty mean auditing script. Since variables you assign in the WebQuery events aren’t saved, the only way I could track changes in the document currently being edited by the user was to actually create a temp document that stores the values of the document at it’s opening. Then, when the user saves, the values they’ve toyed with are tested against the values found in the temp document, the necessary audit record is made, and the temp document is deleted. Pretty neat, huh?

Well, there were bugs, of course. Due to the stateless nature of the web, sometimes temp documents are orphaned if the (always scatterbrained) user closes down an edit window before he/she has saved — the WebQuerySave event never fires on the server, and the temp document is never deleted. There’s a quick and easy fix to that, though — just have an agent run every night, deleting any orphaned temp documents from the previous day. Have it run at about 2 a.m. or so — that way the unlikely scenario of a user editing a document at midnight and his changes not being audited won’t occur.

(Now that I think about it, I guess I can try using the JavaScript “onunload” event to somehow control what happens if a user closes down a window without saving — I’ll have to look into that.)

Another little problem happened when I tried to test the app with a test user who was barebones in the way of file permissions (up until this point I had been testing it with my own Designer-level access) — you can probably guess what happened, eh? No changes were audited! Why? Because they didn’t have enough access to create temp documents! Doh-doh!

Well, that was a simple fix — just uncheck “Run as Web User” on the agent properties box. That way the agent will always run as its designer — also, logging the current user’s name has to be taken care of with the CGI variable “Remote_User” instead of the more typical Session.EffectiveUserName.

So, there you have it! I’ll try posting the code one day, once I’ve taken it apart and made it portable.

Once I’ve gotten rid of any more bugs, of course.

Fixed Agent Running Problem

Finally fixed that annoying access problem! Turns out I didn’t need to give Create and Delete access to the Default user at all — I just deselected “Run as Web User” in the properties box. Now, it takes a little more finagling to get the current effective user name (actually, you just grab it form the CGI variable “Remote_User”), but hey — it works!

Noos you can uoos