Browse Prior Art Database

Mail Merger

IP.com Disclosure Number: IPCOM000235050D
Publication Date: 2014-Feb-26
Document File: 10 page(s) / 99K

Publishing Venue

The IP.com Prior Art Database

Abstract

A technique for generating a unique view by consolidating multiple mails from different tracking systems, using mail client based on user defined mapping rules and templetes. During collaborative develeopment using mutliple tracking systems one has to deal with many notification mails , Each of these mails has specific format or template understandable by user and conatining a series of fields that demarcates the status of the task in development . By creating a template for each of these tracking system and mapping the fields , upon on reception of mails , shall be parsed against the templates and Consolidated and interested views can be generated .

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 28% of the total text.

Page 01 of 10

Mail Merger

The solution proposed is a rule and template based , which will consolidate multiple notification mails sent to a user from different defect/work tracking system and present it in a unified form which can be accessed offline. The solution will also provide a facility where in the user can create relations between individual work items irrespective of back-end system to which the work item belongs to. Any incoming mails related to a given work item will be automatically processed to change the document as desired by the user.

There are multiple solutions in place which allow users to merge mails with the same subject into a single document which can be referred as a single document. However this merging system lacks multiple features. Some of them are listed below for clarity.

~ Offline availability of items as a single read only document in the mail client. ~ Link mails pertaining to different items from different systems, which

otherwise are related to each other. Example a RTC work item which has a corresponding JIRA work item.

~ Ability to fetch other information about items.
~ Ability to fetch child items via simple mailing interface.
~ Ability to flag status changes which come via emails into visible changes in

  the way the item looks - user friendly colour coded way. ~ Ability to maintain rules that can be shared across group.

System used definitions:

Defining various system used shortly

Work item management system

This is a system which is used by a collaborative development team. The system has a capability of creating work items which are used to manage, track and deliver work in smaller units.

A work item can be defined as a unit of total work, which has a unique identifier in the whole system and can be managed and delivered individually. A work item has multiple attributes which defines the work. Some of attributes can be defined as type, summary, description, status, severity, priority, target component, owner, creator, create date, delivery date, approval records, a stream of comments. Work items can be related to each other through multiple relations (children, depends on, blocks etc.)

The system has a capability of letting people subscribe to the work items so that they can be notified about any of the changes that happen. The system sends out emails about any change in the work item to people who have registered for such

1


Page 02 of 10

information. System automatically subscribes people to the work items owned by them.

Team member

A team member is a person who performs one or more roles in the team

He/She owns delivery for a number of items in the system

OR


He/She manages a team who own multitude of items

OR

He/She carries out a parallel activity which is related to multitude of items

OR

He/She is dependant on one or more items to be completed in order to continue his/her work

OR

He/She is the reviewer or Approver of multitude of items

OR

He/She is interested in the Progress and information in the item...