Tonight I'm happy to release the beta of Lighthouse 2.5. There are a lot of major changes here, so I thought I'd release it as a beta and let folks play with it a bit first. So what's different?
- New design by Justin Johnson, designer of the new CFLib.
- Milestones can be created for projects, along with an optional due date. You can then assign issues to milestones.
- There was a major change to the Ajax code behind the project view. In the previous versions, all the data was loaded on the first load. This made sorting/filtering super quick, but when projects got a bit large, it made that first hit really slow. I had a client with 400+ bugs, and it got to be pretty unusable. I switched to using Ajax to load a page of data at a time. So when you sort, or filter, it does a new HTTP request, but since it's just passing JSON around, it should still be pretty zippy. My feeling here was - keep the funcitonality the same - but ensure that larger clients wouldn't be 'punished' speed wise. Hopefully this works out well for folks.
- As part of the above change, I switched from Spry to jQuery. This was not done because Spry couldn't handle the functionality. It was done so I could play more with jQuery.
- The application includes some basic documentation in itself now. So for less-technical users who are new to the idea of issue trackers in general, we can provide them with a bit of direction.
- ColdSpring. More on that in a sec.
- When you edit an issue, the email was always pretty good about detailing the changes (status changed from X to Y), now the history field will do the same thing as well.
Ok, some quick screen shots:
Login Screen

Home Screen

Issue Screen

You can find the download below. Please note that this is beta, and should be handled with care. The readme tells you what to do on the database side. I'll blog a bit later today about the ColdSpring integration. I may also blog a bit more detail about the Ajax change if folks are interested.
Archived Comments
These updates look great! I've been using lighthouse already for some really large projects over the past 5-6 months and it's been a life saver.
There was a couple of things I wound up tinkering. I disabled emails because my group was in lighthouse almost everyday and the quantity of emails was too great. I flipped the ordering of notes so the most recent was on top, and made the issue text area a giant fckeditor window so we could do things like past email content with lists and links.
Excellent, I must try out this beta. Looks pretty. :-) Well done for using JQuery. (I'm actually using JQuery to fetch, parse and display RSS feeds instead of cffeed)
I've often needed to add lists to bug reports. Using an asterisk as a bullet point is not ideal. How easy is it to add fckeditor with just a few basic formatting buttons?
In theory as easy as replacing the textarea tag. I leave that to others though, as I'm anti-RTE. ;)
Works for me - thanks.
Scott, didn't you tell me you had a _large_ dataset? (Heh, that's what she said.) Is the new ajax system working ok for you?
Looks awesome. In the process of trying it out. However is there a 'lh_milestones' table that's supposed to be there? It's not in the setup scripts. Unless I'm overlooking something.
Ahem:
"The readme tells you what to do on the database side."
;)
Yep - over 2,000. It is zipping right along now.
Very Nice ... I'm Installing It ...
"Getting Started" link gives me this:
Element VERSION is undefined in APPLICATION.
Maybe I missed something else to do in the readme file. Really not understanding this sort of scattered approach, with an installation file, then a readme file that initially looks like just a changelog & credits & licensing but then also has necessary information in it...
@JC: Bug confirmed, and fixed, and I replaced the download.
I respectfully want to disagree with your 'scattered' approach. All of my apps have used this system for years now: An install folder with full installation instructions, and a readme.txt file that explains changes from one version to another. Because this is the beta, I used the readme to explain what to do for the update. There will be a full 'upgrade' doc when I release the final version. Although the readme will still be there for folks who are curious.
if only there was an installation package for coldfusion apps.....
Thanks Ray. Yeah, on your other apps I've tried, the info that's needed is in the install.doc. That's sort of what I was getting at. Since it's beta you're doing it differently, which confused me. :)
Additional issues exist on user_edit.cfm (Element PLAINTEXTPASSWORD is undefined in APPLICATION) and milestone.cfm (Element PROJECT is undefined in URL.)
I assume milestone.cfm would probably work if I had a project, though.
JC, I confirmed the first report. For the second, did you mean to say milestones.cfm was broken? You should not be able to go to milestone.cfm until you add/edit.
Or did you manually enter milestone.cfm in the URL? If so, that's your fault. ;) But I can look for it and send back to milestones.cfm.
Sure you can... click the + sign next to Milestones link. :)
Good catches! All fixed.
Looks good now! Looking forward to playing with it :)
Hey Ray! Not sure if this would be a bug or not, but if a user updates an issue without modifying anything or adding a note, it still generates an email.
I sent it to my boss to play with and just got a bunch of emails from him looking at the issues I posted and saving them to get back to the issue list screen.
That's normal. I _could_ add code to see if nothing changed, but on the flip side, a person could use this feature to help push certain issues to the top.
You could always add a *bump* button to throw some text in if they want to do that. Or javascript to grey out the submit button if there's no text in the box. heh.
Not a big deal I guess, but I know from our existing Altiris system, which we all loathe, we have a few users who always open the darned thing in edit mode to read it and then save it, with no changes, which then emails at minimum half dozen people, some of them twice depending on the settings for the incident. But I wouldn't use this for most of those users I guess, just for our web dev group, possibly even just for myself to help keep my 8 #1 top priority drop everything else projects organized. :)
You know, that's a good point. Would you mind bringing it up to me after the release, or filing it as a bug report on RIAForge?
Hi, I noticed a bug with e-mail send as issues, this bug is in the view.cfm where different items are "changed" to there new values. A e-mail issues has empty values and you get errors about the value not being a uuid. I changed view.cfm to check if the value is empty and everything works. The check was already done with milestones but not with the other fields.
if you like I could send you the file.
Also, i changed the status table with a "show" column to let me choose to show the status in my overview of issues or not. We have a status "closed" and I don't want to see those status in my overview.
If you like I could also send you this change.
One project dropped from 600+ issues to 80+ that actually mattered :-)
Another note: I changed the mailprocess.cfm in this way that e-mail in the mailbox that is not assigned to ANY of the projects in your setup is deleted from the mailbox as well. After checking the debug mode I found out that one mailbox was filled with about 200+ spam mail.
Oh.. and thanks for this great app!! I almost forgot to mention this :-)
I'd like to get your mods Tjarko. But now the one for show. That one I don't want to integrate. Please and thank you.
Folks, I fixed a bug with pagination, but I haven't pushed the fix up here. I'll push it aftr I get these other mods from Tjarko.
Zip updated again. Fixes pagination bug. Fixes a mail server setting issue in App.cfc.
Hi Raymond, I have tried 3 possible e-mail addresses now but the keep on bouncing for me :-( Could you send me an e-mail at tjarko at carlosgallupa.com?? That way I can send you the 2 small changes. Txns!!
Long-time LHP user here; I've got the beta up and running. A couple of items for consideration:
1) The SQL at line 453 in components/issuemanager.cfc won't run against MS Access without modification. I've used LHP on a couple of small projects with Access for several years w/o problem but had to tweak the SQL to get the beta to work. I'll follow up off-line with updated SQL that should continue to work on other DB platforms but also works on SQL.
2) RE the new layout, please consider going back to an elastic page layout that expands and contracts based on the browser window width.
I updated the zip again. It fixes Ron's Access issue, but as I can't test, someone else will have to. I tested on MySQL of course.
I fixed an issue from riaforge where sql server complained on the search. It didn't throw an error on mysql, but my fix should be good.
I fixed _another_ bug I can't reproduce, involving MilestoneDAO as well.
@Ron - as to your 'make it wide' rule, I'd like that as well. If someone can share the CSS fix, I'll gladly include it.
I want to wrap this up by Monday I think.
Hi Raymond,
We have been using the previous version of Lighthose for the past year. Is there any way to maintain the data in the old DB after migrating to version 2.5? Thanks so much for creating such a useful progrm!
Regards,
Mike Flach
I don't know how old your LHP is - but I don't see why you would not be able to migrate the data. Most of my changes have been additive.
How, where, or do you need to add the coldspring intergration for version 2.5 of lighthouse?
After I installed the code I get the folowing message
Could not find the ColdFusion Component or Interface coldspring.beans.DefaultXmlBeanFactory.
The readme tells you what to do on the database side. I'll blog a bit later today about the ColdSpring.
Just go to to coldspringframework.org. You should NOT be using the download here. You should be using the download from riaforge: http://lighthousepro.riafor....
Hey,
We're currently using Trac, mainly for the SVN integration. We'd like to do away entirely with the Python dependency on our beta/testing/bug tracking server.
There isn't a whole lot of documentation to be found on Lighthouse, though. Are there any plans to integrate with an SVN platform? Or does this already exist? Know of anyone working on it?
It's nice to say 'bug #344 closed with svn commits #1043, #1045 by user X,Y' With a direct copy of the code changed.
Should be fairly easy to do in Java. If it's not available, perhaps I can attempt to tackle it ?
So I've given some thought to this before. In theory you just need a SVN postcommit hook to send the data to a CFM that would accept it. The issue I have is authentication - you would have to trust the URL request from SVN.
So I've "thought" about it, but haven't tackled it. I'd _gladly_ look at any submission you may have in this area.
@Ray.
This might get a little long, so I am hoping to perhaps communicate with you about this perhaps via email.
I am willing to take on the issue, but am in the discovery phase. There are many alternatives to URL based SVN integration. There are a few Java libraries that provide complete solutions for integrating with SVN servers. The ones I am thinking about aren't JRE standard, though. So installing Lighthouse with SVN would require either an additional script, or user interaction.
There is also interaction via command line. This requires that we have a bin copy of SVN available to the module. If this module is above the web root... without some sort of protection it could prove very insecure.
Then, of course, there is URL interaction. If the Repository is initially setup by an admin with each user having a unique user name and password... it should be fairly secure?
I have used the second two methods before, in various ways. Once we had an outsourced team work on a 'beta' copy. We had a url available to them that would allow them to push that committed code to trunk which would be the beta site and then another script to push the approved changes to the production server.
The second way is how all of our developers interact with SVN. We haven't had many issues with it and this is how we have trac set up. Trac merely keeps a text copy of the changes instead of attempting to query the SVN server each time you would like to see change #X. This might be the most advisable way to do it ? We would just need to setup an SVN specific table that stores change X to issue Y to posting user Z.
Plenty more to talk about, but I would like to hear your concerns about URL based integration. I am thinking about taking it on this weekend, although it will probably take a bit longer to complete and be test worthy.
Well, in theory, LHP could generate a project key, a unique value, let's say it's N but imagine its a nice long UUID. Your SVN post commit hook could then simply be to hit
LHPInstallroot/hookprocess.cfm?key=N
If the "key" gets out, then you are screwed, but we could provide a simple way to generate a new key per project. As it stands, I doubt many people use LHP on a publicly accessible site anyway.