Posted in ColdFusion | Posted on 09-28-2008 | 4,857 views
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.
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.
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?
"The readme tells you what to do on the database side."
;)
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...
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.
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.
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.
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. :)
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 :-)
Oh.. and thanks for this great app!! I almost forgot to mention this :-)
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.
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 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.
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
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.
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 "thought" about it, but haven't tackled it. I'd _gladly_ look at any submission you may have in this area.
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.
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.
[Add Comment] [Subscribe to Comments]