ClearQuest Email Notification Package Reasons

From cqwiki
Jump to navigationJump to search

Why the package was created?

I was not satisfied with the functionality provided by the standard solution. Let me give you a brief overview of ther features that we (do not) have in the standard package distributed with ClearQuest.


Top three features of the standard package that I do NOT like

Inflexibility

Notification configuration is limited to selection of fields that are included in the message. Can you create custom subject with pre-configured text, or provide detailed instructions on why he or she received the notification and what needs to be done? Yes, you can, but you would need to create a field with solely purpose: to keep the text to be included in the message. I do not think that it is a great idea to extend data structure with a bunch of unnecessary fields.


Unreliability

If notification is not sent due to mail service unavailability, client’s misconfiguration, antivirus block, or any other reason – it is lost. You will never be able to find why it was not delivered.


Terrible configuration

Notification settings need to be configured on every single client. It is not too bad when you use CQWeb only, but imagine what it cost you when you have thousand of fat clients installed. How simple would it be to change settings, for example, smtp host? When you enabled notification on a client, it is enabled for all databases accessed from the client. It does not matter, whether it is a test or production database – it makes it very complicated to develop and test notification rules. Finally, a user could simply turn off email notification on his or her machine, and you can do nothing about it.

Personally, I do not understand why the vendor of so powerful tool as ClearQuest cannot offer something better for their customers.

What options do we have?

You know all disadvantages above even better than me. I do not use standard package for years now. You might be frustrated, but what are the options do you have?

  • You can continue using standard package and simply decline any enhancements requested by your customers, since they cannot be implemented. The advantage is that you have supported solution. Unfortunately, it is the only advantage.
  • Another option could be to develop your own, custom made, notification hook. (You might be already have one?) The benefit is that it is your own solution, but do you need to update ClearQuest schema and upgrade user databases when any change is required? Is it easy to deploy it to a new schema? Is it easy to support in multiple schemas? I think, you know it better.