Hi,

Only started using osTicket this week, was looking for something I could get up and running quick to help easy my 'support' work load, ideally open source so I could help develop / integrate it and very pleased I found this!

I've listed below some bugs / features I'd personally love to see in the official version, have logged the bugs under the 'bugs' project.

I'll probably end up doing some of the features I'm looking for myself over the next few weeks, that got me wondering what the future holds for this project? Is it in active development still? Are feature requests taken seriously? Do the development team accept and integrate patches? If so, what's the official way to submit them?

Mark

Feature Requests

* OpenID for 'scp' login

* Default focus on 'scp' login -- very annoying !

* Default focus on open ticket for end user to be on first field

* Optionally (not all users will want this I guess) If only one Help Topic then New Ticket should have that pre-selected as pointless asking the user to select the only one available topic

* Optionally select one topic as 'default' to be preselected

* Optionally include Department names in Help Topics drop-down

* Optionally be able to group by 'customer' -- maybe by the email domain or something? -- for customers' managers that want to see ALL their tickets

Bugs

* Sort order on 'effective_date' on staff ticket list is the wrong way round (lose the DESC) on line 202 in tickets.inc.php

* Departments that are set as private, the Help Topic still appears for end user to open new ticket against

* Some premade replies seem to be getting cut off (actually stopped using this feature 'cos of this bug so no longer have examples of)

* Seems a little odd having the 'Staff Panel' and 'My Preferences' for non admin users as you can't really do anything else and Preferences is available via My Account

7 days later

Hi,

Do I take it from the lack of any kind of response that this project is, in fact, dead as is suggested in various other places around the net?

Real shame if that's the case as from what I can see the system is 'almost' what my business needs right now, sure there are others in the same position.

Mark

Do I take it from the lack of any kind of response that this project is, in fact, dead as is suggested in various other places around the net?

It's definitely not dead, maybe it's in a zombie state ;)

The "various places around" in general refer to the status before the "(rebirth)". However, I'd say everyone can easily do the math themselves.

I never know what to answer when people ask me about osTicket's status, or its outlook. But at it's currently questionable state I am having a hard time to even justify our installation. My main argument so far is that osTicket is easy enough to hack myself. YMMV.

HTH.

-- xrat

Disclaimer: According to (Kelli) I am holier-than-thou when I disagree and I can be a reckless and irresponsible brick wall. Indeed, what I write comes without warranty. Read, understand, and live at your own risk. Please, note that I am not affiliated with osTicket.

Mark,

Thanks for your feedback. I'll look over your list in detail this weekend, when I get some time. Some of it looks like issues we're addressing and adding already.

Just a note about feature requests in general (this isn't aimed at anyone specific): We accept feature requests but they have to make sense within the scope of the application roadmap, particularly when they arrive in the middle of a big development cycle. Part of the job of developing the script is knowing what to leave out as well as what to put in. Part of the apeal of osTicket is that it has a lot of useful features and not a lot of bloat.

As to the development status of osTicket - it has, for the past several months, been very much in active development. In fact, probably moreso than it's ever been.

We've just been quiet about it because there's a lot to do and we're extremely busy this time of year with a number of projects, so it's hard to give any kind of timeline or projections for when things will be released. That's also why we've been quiet on the forum lately. We're just swamped. The forum is intended for the community and we post here when we have time. Lately, we just haven't had it.

I realize this may make it seem like the project isn't very active, but that's not the case. We don't like doing incremental releases followed by lots of patches and bugfixes. While the "release early, release often" mentality that has become so popular as of late may work fine if you're doing iterations on a centrally located web-app, it's nothing but hassle for distributed software maintained by the end user. We're more inclined to take the slow road, make releases more meaningful, and make sure the code is thoroughly tested.

We (Peter and I), have a very clear vision of where we want osTicket to go and great progress is being made.

Trust me - it will be worth the wait. I really think people are going to love it. I'm extremely excited about it.

Kelli,

Thanks for taking the time to give a detailed reply, I'm sure it's answered a few questions for others reading the forum as well as mine.

Must confess having not heard anything for a while though I've taken a similar view to xrat in that I've just hacked away at it myself to get it working for me, of course the danger now is that if you do another release and not fix some of the issues I have I'd be potentially stepping backwards if I did an upgrade. Also I have changed a few things now such as only showing the 'open' number of related tickets from the view ticket page as well as changing the default query to be 'open' instead of all to match the counter.

You say you have a Roadmap for the project and "a very clear vision of where we want osTicket to go", I did find a previous post saying "A public roadmap for osTicket doesn't exist and, to be blunt, never will." so now that you do have one, hows about sharing it with the user community?

On the subject of bugs and feature requests, I've worked on other open source projects in the past and we've used things like Trac, which I'm sure you are familiar with, to allow users to log bugs and feature requests and, more importantly, allow non development team users to submit patches and attach the patch file to the relevant issue. This has several advantages, in my opinion, to all concerned as it allows anybody to potentially work on the project while at the same time allowing yourself to keep the control you spoke about, i.e. to decide if it's right to include the bug fix / feature at the current time of development, while allow users to potentially get the features they want right now and still keep their local copies in a state that is upgradable.

Another plus of this way of working too is, as there appears to be only the two of you developing on the project, I know as a developer myself we are the worse people in the world to test our work at times, making patches to bugs etc. publicly available this way if potentially getting you thousands of testers before the fix is included. I did sort of find this submitting patch way of working happening while searching the forums, although there doesn't appear to be any formal way of users to do this, as such. Also there appears only to be a bugs section and not one for feature requests.

Mark

Mark, thanks! I really appreciate the thoughtful feedback.

Our stance on it is probably going to sound very opinionated, which it somewhat is, but please don't be offended by it.

The fact is, both are true-we do have a very clear vision for where we want osTicket to go, and there is not/will not be a public road map. There may be more information released as we get closer to a release date. I really don't know. It's not something Peter and I have discussed at length.

I understand what you are saying, though, and I agree that, for a large number of open source projects, it makes a lot of sense. osTicket is a bit of a different beast, admittedly, by our own choice.

Peter and I develop the software and then release the source for free. It is not, by any stretch of the imagination, a community developed project. With the rare exception of the occasional urgent bug/security fix, we don't accept code from the community. This, I believe, is really the whole crux of the issue.

There are a number of very good reasons for this, but out of respect for Peter, I'm not going to go into them here, because I'm not sure what he wants said and what he doesn't. I'm going to have to ask you to just trust me on this one.

We're all for gathering feedback from the community, and we're all for members of the community modifying, adding to, fixing, and improving upon osTicket and making those changes available to others, hence, the forum and the bug tracker, but we're not going to change the way we develop osTicket. The official codebase is always going to be the code that Peter and I write.

That said, I'm not opposed to the idea of making improvements to the bug tracking/feedback systems we use. We were discussing it just the other day, but it's not something that's likely to happen before the next release. It's just way down there on the list of priorities, with the actual development coming first.

I hope this doesn't sound harsh, because we really are grateful to the community for all of the support and feedback they've given us over the years, and I'm sure there are a lot of very talented developers out there in the community, so please don't take this stance as any kind of statement against their quality or capabilities. It is simply the way we have chosen to develop the software.

As to "taking a step back" when the new release is made, once you see it, I'm confident you won't feel that way. That said, whenever you do any customizations to the script, you always run the risk of losing something when the new version comes out, and making changes, particularly to the database, always carries the risk of complicating the upgrade process. It's just an unavoidable consequence. We do our best, though, to fix bugs, so you're not going backwards as far as actual errors in the code are concerned.

I can tell you right now, OpenID will not be supported. Changes to the way help topics and customers are handled will mean yes, you may, in a sense, lose some of the functionality you mentioned above, but you also won't need it, because the new system will address these issues in its own way. Consider it more of a step sideways. ;)

Testing - Excluding, for a moment, the fact that Peter's ability to find bugs within my code borders on the supernatural, we're well aware that two developers do not a good test case make. I'm sure the next version will go through some vigorous testing before it is reelased, though we haven't worked out the details just yet*.

* Please don't send us a bunch of emails asking about this. When we figure out when it's going to happen and how we want to handle it, if we people to test, we'll announce it then.

Kelli,

What is the big objection to using OpenID? (I'm only taking about the Staff interface btw). Have to say it's a pretty major thing for me to some extent, I was at one point in the situation, like many I'm sure, where I had file after file of 'customer' username and passwords lying around, OpenID has been a god send to me. The code is fairly minimum and probably would just need the username field in the database extending a bit.

Mark

Kelli wrote about OpenID in late 2009 in the thread (openID logins for system and forum).

I've reconsidered a bit since then and will concede that it's maybe not as useless as I felt it was at the time. :)

That said, it's low pirority.

Write a Reply...