It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,877
×6,111

question asked: Apr 16 '13, 12:08 p.m.
question was seen: 4,618 times
last updated: Apr 22 '13, 1:19 p.m.

Related questions

HELP!!!.. required fields are killing us.. solved, customer provided workaround

0
sam detweiler (12.5k●6●195●201) | asked Apr 16 '13, 12:08 p.m.
edited Apr 21 '13, 10:30 a.m.
we need to turn on required fields for defects for our 160 projects..  but this is causing a fatal production line stop.
  1. the earliest state is New.. but we have a ton of workitems in New state. and they get fiddled with while in New state. we need a required on Create action.
  2. you cannot change a block of workitems (bulk) when u have to change 5 fields.
  3. IF we were forced to use NEW.. I need NEW from today forward.. not all the existing workitems.

we are on rtc 3.0.1.1.. not 4.0.1/.2 (ie, not current)

help!!!!!!


Comments
Kevin Ramer commented Apr 16 '13, 12:15 p.m.

Sam,
It's my understanding that not burrowing into the hierarchy of the Required Attributes pre-condition would make the required attributes required on any save.
 

Daniel Toczala commented Apr 16 '13, 3:41 p.m.
FORUM MODERATOR / JAZZ DEVELOPER

Sam,


  If you make fields required, then the existing defects will need these fields set the next time that they are saved.  Now that would mean that you would not be able to do a bulk change (since you can only specify a single field), which makes sense to me.  Is the issue that you want the current batch of defects NOT have these fields required, but any new defects to have these fields required?  Is the issue that people don't know the proper values to assign to these required fields in the existing defects?  Is it both things?

sam detweiler commented Apr 16 '13, 6:16 p.m.

Yes, it is both things.  we have run for 18 months with no structure of required fields and are starting to do enforcement now, but there is a lot of cleanup.
some of the required fields are new in the template (Detected By, who reported it)
and a product Feature field (that has to be customized for each project).  so the developers never saw them and knowing WHO reported the issue 1 month ago may be hard to figure out.

and we only added 4 required fields!..
severity
feature
detected by
and Found In - many teams have not been diligent in using this field, cause it really doesn't represent our way of working.

so, while I agree that we need to cleanup, we also need to be able to move forward reasonably.. cleanup is extra work.

Accepted answer

0
permanent link
Stephanie Bagot (2.1k●1●5●13) | answered Apr 17 '13, 3:29 p.m.
FORUM MODERATOR / JAZZ DEVELOPER
PMR 45487,7TD,000 was created to track this question. Support will continue working with Sam on this issue.
Stephanie Bagot selected this answer as the correct answer

5 other answers

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Geoffrey Clemm (30.1k●3●30●35) | answered Apr 16 '13, 11:37 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
edited Apr 16 '13, 11:38 p.m.
One workaround is to create a new work item type with the required fields, and prevent your users from creating instances of the old work item type.
Comments
sam detweiler commented Apr 17 '13, 1:46 p.m.

ouch.. we have enough trouble managing the existing workitems..

0
permanent link
Ralph Schoon (63.5k●3●36●46) | answered Apr 17 '13, 3:57 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Another thought would be to define a role e.g. Admin for you and your team as admin that does not enforce the required attributes. Then do your cleanup and assign reasonable values.

All other roles will retain the requirement for the required attributes and will have to update work items as they go.

I find this the cleanest thing to do. It enforces to set the required attributes when users want to save, but it allows you to operate as required.
0
permanent link
sam detweiler (12.5k●6●195●201) | answered Apr 17 '13, 1:45 p.m.
sorry, Ralph

I need to turn it OFF for all users of OLD (prior to today) workitems,
and ON for all users of all workitems created today and forward.

then the teams (across our 3500 people) can clean up the OLD workitems as they can.
Comments
Ralph Schoon commented Apr 17 '13, 1:53 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Then I think you have to disable it completely and run fixes with a queries before enforcing them again or follow Geoffs suggestion. 
0
permanent link
sam detweiler (12.5k●6●195●201) | answered Apr 21 '13, 10:28 a.m.
edited Apr 22 '13, 11:11 a.m.
PMR results (not surprizing) 'working as designed', I am not keen that they copied the results from the forum answers above as 'the answer'.

so, I took the source code and added 2 lines of code and one XML element..  now it does what we need.
(I didn't try to update the advisor configuration UI) We will install our version along with the product version.
the product version will do required fields for ending states, regardless of prior state ('New' state with prior state of 'New'). Ours will check for being created. ('New' end state, with no prior state.)

so the advisors work like this (joining all the required fields lists together)

all workitems  
  + all of this type
     + all in this (ending) state
         + being created   - new capability  (ours)

can someone change the accepted answer to this entry

I 'could' completely replace the original function with our plugin, but the test requirements go crazy.

0
permanent link
sam detweiler (12.5k●6●195●201) | answered Apr 22 '13, 1:18 p.m.
edited Apr 22 '13, 1:19 p.m.
I have opened this enhancement request

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.