Bug 853022 - BPMN Editor Does not Show Service Task for any further new Work Item Definition(s) if definition as corrupted
BPMN Editor Does not Show Service Task for any further new Work Item Definiti...
Status: CLOSED DUPLICATE of bug 853496
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: BRM (Guvnor) (Show other bugs)
BRMS 5.3.0.GA
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Tihomir Surdilovic
Lukáš Petrovický
: Reopened
Depends On:
Blocks: 853496
  Show dependency treegraph
Reported: 2012-08-30 05:39 EDT by Johnathan Ingram
Modified: 2012-08-31 14:18 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 853496 (view as bug list)
Last Closed: 2012-08-31 14:18:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Johnathan Ingram 2012-08-30 05:39:39 EDT
Description of problem:

Once a work item definition is corrupted in the repository, no other new work item definitions will appear on the BPMN web editor service task pallet.

Version-Release number of selected component (if applicable):
5.3 Guvnor

How reproducible:

Should be able to reproduce

Steps to Reproduce:
1. I created a default work item definition in Guvnor.
   It showed up correctly in the BPMN web editor under the service task pallet.
2. I then modified the work item with a missing " in a parameter name, saved
3. I then changed the name and display name of the broken work item definition.
4. I then created a new default work item definition and saved.
5. From this point no new work item definitions appear in the web editor service task pallet.

Additional info:
I had to recreate the repository in order to get the work item definitions working again.

I also tested adding a work item definition to deploy/designer.war/defaults/WorkDefinitions.wid.st after a work item definition was corrupted, and this also did not show up
Comment 1 Johnathan Ingram 2012-08-30 07:19:50 EDT
This issue may be worse.

If you change the name & display name of an existing WID in designer.war/defaults/WorkDefinitions.wid.st, no further wid's can be added to the system until such time the old WID name is deleted manually from the repository.

This is a critical bug as if you rename or incorrectly define a WID, the entire system becomes unusable in terms of further WID definitions.

Please address urgently and provide a patch for BRMS 5.3
Comment 2 Rick Wagner 2012-08-30 10:44:37 EDT
Hello Jonathan,

Thank you for taking the time to enter a bug report with us. We appreciate the feedback and look to use reports such as this to guide our efforts at improving our products. That being said, this bug tracking system is not a mechanism for requesting support, and we are not able to  guarantee the timeliness or suitability of a resolution.
If this issue is critical or in any way time sensitive, please raise a ticket through your regular Red Hat support channels to make certain  it receives the proper attention and prioritization to assure a timely resolution.

Alternatively, if you are a community user of JBoss ESB, please open a ticket on JIRA.  JIRA is the community bug tracking mechanism and will put attention on the problem through the community channels that support the open source project:  
For information on how to contact the Red Hat production support team, please visit:

Thanks again, and thank you for using our software.  I'll close this Bugzilla now, as it will not be processed properly.  

Comment 3 Rick Wagner 2012-08-30 10:58:41 EDT
Hello Jonathan,

Sorry about the previous note, I had recycled some text from the previous SOA Bugzilla and failed to change 'ESB' to 'BRMS'.  Please forgive this laziness.

Would you please open this issue again via either a support channel or the community?  We recognize this as a serious problem and will love to help out.  We just can't work the issue as it's presented on this Bugzilla.

Thank you,

Comment 4 Johnathan Ingram 2012-08-31 04:33:06 EDT

This bug is referenced from Case 00698771
This is a real bug.
Why have you just closed it?
Please do not ignore real issues like this, specifically if the bug has been logged with a case raise!!!
Comment 6 Rick Wagner 2012-08-31 10:28:54 EDT
Hello Johnathan,

Thanks for voicing your concern over this issue.  We are looking at it.

Please don't be alarmed if you see this Bugzilla closed or otherwise modified as you would not like it.  The reason is because this Bugzilla is not part of our normal workflow process and won't be part of the solution you seek.

The support case you opened (00698771) is proper.  This is the correct mechanism for getting problems solved.  Based on these cases, our support engineers will open Bugzilla issues as necessary.  These will be processed and made part of patches and upgrades that address problems.

To say that again:  Bugzilla issues from non-Red Hat employees are not worked upon.  Bugzilla issues from Red Hat employees are worked upon.  The way to get a Red Hat employee to open a Bugzilla for you is through a case.

In the interest of total honesty, I will also tell you there is one exception to this rule.  If you find an issue that deals with documentation, you may open a Bugzilla and it will be treated as valid.  Sorry for the crazy rule, but that's the way it is!

Thanks again.  We are working on your case, you should see action on through the support channel.  Please don't be alarmed if this Bugzilla goes closed again-- there will probably be another one opened for this issue (with the proper Red Hat opener backing it) if one is necessary.

Best Regards,

Comment 7 Alessandro Lazarotti 2012-08-31 14:18:38 EDT
Hello Johnathan,
As commented by Rick we should close this one. 
A new BZ was created to drive this issue (see Bug 853496).

If you have some question about this, please report in the support ticket 00698771


*** This bug has been marked as a duplicate of bug 853496 ***

Note You need to log in before you can comment on or make changes to this bug.