Ringing the Death Knell

As of today, Wednesday, July 9th, all the large components of the new ticketing system have seen light. The ticketing system is ready to move from core development into pre-QA and QA.

What needs to be done:

  • There is a join cap set by Alchemy of 32 joins. Because of the very hefty new database schema, this can easily be reached with just 8 ticket queries. Therefore, the join mechanism in the TicketQuery needs to be upgraded. This is actually the highest priority item right now.
  • Add the Dojo font-end for creating, deleting, and changing fields. This will be done by Jeff and is probably a small step in the development process despite the fact that it is central to the system
  • Integrate the Dojo upgrade into newt
  • There needs to be extensive functional testing
  • The unit tests should be run to ensure that newt fails exactly when trunk fails and for the same reasons

Bug issues seen so far:

  • The field name and the field preview on the Ticket New and Ticket View pages should be wrapped and scrollable, not overflow the table
  • Tags do not work for new tickets
  • Users cannot change email notification defaults in project preferences
  • The ticket query sub-system needs major testing

Enhancements I foresee in the near future:

  • The kid templates make judicious use of CSS, but there are still a few tables used (namely when assignig field values); perhaps layout can be implemented with CSS, not tables.
  • There is currently no option to view the cross-project ticket query results in other formats (e.g. comma-delimited)
  • The tags box on the new ticket page is awkwardly placed and will probably be changed by someone
  • Many unexpected errors can be raised in the myriad of sub-components and only DrProject errors (and some others) are handled by the request object majestically. Perhaps the req object will be retrofitted to catch any unexpected errors (I anticipate mainly parse errors) and warn the user without crashing the portal
  • A brief code review would be useful
  • We use JSON to communicate between JavaScript and Python. This will likely be changed to something else until JSON is adopted. This is not so hard since the use of JSON is *highly* localized.

In the past half-a-week, I’ve made great strides in making the code much more modular and readable, and I’ve tried to anticipate security concerns as wells future extension. Security really doesn’t seem to be a big issue (or maybe I’m just not well versed enough in the field).

Enhancements I forsee in the distant future:

  • Cross-project fields. Fields that are, not only named the same across projects, but actually are the same in the database. Probably useful for cross-project ticket queries. I have made no effort to support this.
  • Cross-project ticket queries can be filtered by a very minute set of fields since fields cannot be assumed to be the same across multiple projects. This may be changed in the future by playing some database tricks. Changes here are either easy or they’re not; I can’t anticipate what will be done and so I haven’t made any effort to this end.
  • The ticket query sub-system and its associated controller permit somewhat narrow query formulations. The user can select a field, then select an operation (*is*, for example), then she can select any number of possible values. Notce that she cannot query a particular field in more than one mode (e.g. A *is* x _or_ A *is not* y). Moreover, there was never any need for AND in the old system (almost), but in the new system AND can be very useful (e.g. A *starts with* x _and_ A *ends with* y). This is currently not possible without boolean logic “tricks”. Changes of this nature should not be difficult given the new modularity of the query sub-system.
  • A user is currently notified about a ticket creation/change if she is mentioned in any of the fields of type user for that ticket. This may change so that a user can choose which field changes she would be liked to notified about. I’ve have made the system extensible to this end.
  • The fate of the ‘All’ project and the ‘Annon’ & ‘Nobody’ users are not known and the system may need to change to accomodate this. I’ve made the code extensible to this end.

I’ve also made a great effort to separate ‘model’, ‘view’ and ‘controller’. Recently I moved all the business logic out of the controllers and the databse schemas into the ticket and milestone APIs. “All the business logic” has a subjective conotation of course. I’ve removed all the mapper extensions and have moved user input validation into the controllers. I’ve moved GUI stuff into the kid templates and the CSS files. I feel the system is much better segmented now into logical divisions based on purpose.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: