Helpdesk: Email notifications for Issue Management

[pocketom]

We think about using EA instead of our Mantis bugtracker. But there seems to be no functionality to send email automatically once an defect or feature is reported. Is that possible? Or does anybody know if there is an add-in to support Mantis?

The next step would be to integrate with MS Sharepoint (create new defects/feature requests from a Sharepoint list and add them to an EA 'inbox' package automatically)

THX!

[pocketom]

Nobody here using EA's issue tracking capabilities?

[beginner]

For obvious reasons, I guess. Would you dare to ask what kind of bug tracking is used at Sparx?

b.

[pocketom]

Hi, not sure what you mean with kind of bugtracking but we receive (from the outside-IT world):

• feature-requests (change in EA)
  
• defects (defect/issue in EA)

The initial feature-requests and defects should be created on a public MS Sharepoint intranet site. Either the request ID/URL will be copied manually into EA (create a defect/change/issue in maintenance view?) EA . Or better if possible there should be a connection between Sharepoint and EA (creating defect/change automatically) via SDK. This should be the public entry point of communication for our client requests. Then the request is processes internally and at the end the entry point (the request ID/URL) will be on the weekly report (to close the feedback cycle).

Would that make sence or is there a better best-practice approach?

[Geert Bellekens]

Tom,

I think that approach should be able to work.
We have a slightly different approach.
We have structured the notes field of the EA elements with xml tags.
One of those tags is the workitem in TFS.
Every time we change something in EA we keep a change log in the notes of what was changed and for wich workitem.
Its far from perfect, but it allows us to keep traceability between requests/issues and the changes in the EA model.

Geert

[Geert Bellekens]

Oh, and something else, are you sure you want to make a difference between defects and feature requests?
I've seen very intense debates about this difference in the past, where the outcome is actually pretty similar.
Whether it is a bug or a change request, it still has to be developed.

Geert

[Paolo F Cantoni]

Oh, and something else, are you sure you want to make a difference between defects and feature requests?
I've seen very intense debates about this difference in the past, where the outcome is actually pretty similar.
Whether it is a bug or a change request, it still has to be developed.

Geert

I agree Geert!   In my view Featuire Requests are just defects "further up the line"...  A Requirements Defect, a Scoping Defect, a Design Defect etc...

Paolo

[beginner]

The question is: why should I use a tool which doesn't have any reasonable workflow support. There are quite a number of free/affordable bug tracking tools which are specialized for exactly that thing. EA is an UML design tool. Of course you can tow a trailer with a 911 (or to have a better relation: cruise with an Unimog).

b.

[pocketom]

Of course you can tow a trailer with a 911 (or to have a better relation: cruise with an Unimog).

You just don't see the benefits I think. We already have a bugtracker (MANTIS). So we could use it further. But since years, this is just a stupid, dead text log (to prove that we actually do somehow any work...). But does it help us that much?

Basic assumptions
1. We are model driven: No code, no deliverables without a structural & behavioral model first!
2. We are test-driven. No deliverable without at least 1 test case per use case

NOTE:
If this is not the case for you, a traditional bugtracker could make more sence.

Features/Defects/etc...
-> All those requests

• potentially change the model (especially use cases and classes)
• potentially change the test cases

So, what do I want to keep track off now? Writing a cumbersome bugtracker log? Writing a dead-text-log just for the sake to make someone else happy? Or just to be able to say: "I'm doing QA!"
For sure not...

I want to know which request (no matter which type of request) changed what elements in my model, when and on whoms intention, how and who has desigend it,  who has implemented it,  who has tested it and when has it been released (who has released.... did I forget something?)


That's why we actually take the UML element 'Information Item'(stereotyped for feature, defect, brainbug,...) and assign it basically with the originating request ID (Properties tab: File->Weblink).
Then we analyse the model. Whatever UML elements are affected in whatever way, we create a 'Trace' relationship, from that model element to the 'Information Item'. Simple.

Finally, imagine that as an contineous, established and ongoing process. Sure you can track that all in a single text log, but just because you can do that since many years that doesn't mean that's efficient or creating much synergy ...

Thinking about relationships
a) What can you derive now from the packages containing a growing number of 'Information Items'?
b) What can you derive now from all the other structural or behavioral elements which can have links to 'Information Items' in the model repository?

Sure, there is no build-in workflow in EA, but anyway we just need reporting at the moment (looking into detail a bugtracker also hasn't that much workflow...). Creating IItems is manual work right now (we will think about creating a MS Sharepoint Add-In). For what else could we need workflows?
The only thing we implemented right now (took ~ 2 hours using SDK and .NET framework) is sending an email when new IItems are created or tasks are assigned (we will create tasks based on IItems soon too..., don't use the static lists further...). Sending theese notifications is also just to help people to get into it...


What do you think? :-?

[Eve]

Correct me if I'm wrong.  What you are saying is that traceability is king, EA provides that and you want to take advantage of it.

Good for you!

Am I correct that the main part of the problem that you haven't solved yet is importing data from a sharepoint list?  What other problems do you have?

I would like to see you succeed at this, even if I need to push for changes in EA for it to happen.  I'm not promising everything you ask for, but would like to hear how EA can be more useful to you in this area.

[pocketom]

Thank you Simon, that's what we want to do. What we need for now is just importing data from Sharepoint. Later there should be reports generated on a regular basis and published automatically in a Sharepoint document library.

One question would be, developing an add-in or better stand-alone (e.g. webservice with scheduler) for the list import?

I've sent you also a PM.

Thanx
Thomas

[Eve]

The choice of an add-in or a stand-alone program makes little difference.  It's just a matter of how you would prefer to start your process.  There are examples for both on our website.  There is in fact no reason why you couldn't write your code to be re-used in both types of product.

Your basic process goes something like this (assuming you already have an EA repository to work with and file open.)

Create a sharepoint object.
Find the list you are interested in.
Loop over the list, and create an object in EA for each entry.

The only part of that that I can really provide help for is creating an object in EA.

I would strongly recommend starting off with a technology containing a simple profile for the element types that you want to create.  You may not need this initially, but if there is any chance in the future that you may want to add additional fields such as who reported the problem then it will come in handy.

First thing your code will need to do is find the package to create your elements.  The easiest way to do this would be to start with a known package guid (example follows) but you could also do it by getting the selected package from the project browser.

Code: [Select]

TargetPackage = Repository.GetPackageByGuid(ElementPackage);
To create the object

Code: [Select]

Element = TargetPackage.Elements.AddNew(Name,EAMetaType);
Where Name should be self-evident and EAMetaType can either be a built-in EA type or a qualified name from a profile, in the form "TechnologyName::MetatypeName".

The example I'm working off here uses the same name for technology name, technology id and profile name.  I'm not looking up any documentation so one of those should work for TechnologyName.

MetatypeName is the value of the attribute _metatype given on your stereotype.

You can then set any any additional properties you need.  For setting the notes, you can use RTF, HTML or text as follows.

Code: [Select]

Element.Notes = Repository.GetFieldFromFormat("HTML",Notes);
After you have set all the standard properties that you want to, don't forget to call Update() on the element.  If you have a field that doesn't fit into those built-in to EA, then you will use a tagged value.  It will look something like this.  (Assuming you have added that tag to your profile)

Code: [Select]

TagValue = Element.TaggedValues.GetByName("Customer");
if(TagValue)
{
      TagValue.Value = MailItem.SenderName;
      TagValue.Update();
}
Repeat for as many tagged values as you have.

Obviously, you can do more.  Adding it to diagrams etc.  But this process should be all you need.

[pocketom]

Hi Simon,

Thanx a lot for your proposal.

So first I will start accessing the Sharepoint list I created yesterday. We've made it simple so that every list entry consists only of

ListItem.ID
ListItem.Title
ListItem.Description
ListItem.RequestType  (feature, issue)
ListItem.ProjectName   (defines root package in reporitory)
ListItem.CreatedBy      (MS Active Directory user acronym)
ListItem.CreationDate  

1. So after I found a way to watch a list from my webservice for new entries(does anybody know if there's a proper eventhandler on the Sharepoint side already, I only see those email based alerts at the moment...?), I'll fetch that into my ListItem C# object and open connection to the repository which runs on MSSQL server.

2. Then I'll locate the target package which should be easy and create the corresponding element.
At this point I'm not absoultely sure what you mean with technology and simple profile. I would choose UML's 'Object' profile, because it contains this 'InformationItem'. Based on ListItem.RequestType I would now set a stereotype (feature, issue,...) for the InformationItem.

That would be enough for a simple proove-of-concept for me.

Outlook
Later then those unassigned Items should be assigned by someone or by pre-defined categories to team members that are configured in 'People' (we imported them as 'Project Authors' from AD, can we access the AD profile later for e.g. fetching email adress, acronym,... or should we better create everybody within 'Resources' better?).

After assigning an IItem to a team member the IItem should be moved automatically in the corresponding team members 'Inbox' package (we simply created a root package 'PersonalFolders', below every member has his own folder which is defined by his 4-digit AD acronym)


Thanx
Thomas

[pocketom]

So, I'm back from my holidays. We've implemented it the other way, some elements are exposed to Sharepoint by creating custom queries on the EA database which we put on a MSSQL server. For some fields(mainly status) we allow to write to the EA DB directly from within the Sharepoint list view. This is working pretty good and simple to realize.

Cheers
Thomas

[Geert Bellekens]

This is working pretty good and simple to realize.

Untill EA decides to change something to the database layout, or you want move to another database, or... :-/
Feels like a maintenance nightmare to me, and I wouldn't allow such a solution at my client.

Geert