I'm able to make the Description field area larger, but can't find where to increase the number of possible characters. Any help is appreciated!!
If you look at the RISK (or ISSUE or CHANGE REQUEST) object in Clarity studio, then you should be able to find the DESCRIPTION attribute (which is RIM_RISKS_AND_ISSUES.DESCRIPTION on the underlying database table (for all 3 objects)) - I don't think you can change its size though from the stock 250 chars.
What I have done in the past is create a custom "Description" attribute to replace the stock one (but you have to create it on the RISK, the ISSUE and the CHANGE REQUEST object separately because the custom attributes end up on the ODF_CA_RISK, ODF_CA_ISSUE... tables) - with the custom attribute you can make a string upto 2000c - if you need more then use a LARGE STRING datatype (which would become a binary field on the database, so has some related limitations).
Of course you also have to change all your "downstream-MI" (portlets, reports, etc) that might reference the stock Description field to now reference your custom attribute - that can be a pain.
Thank you, David. That was going to be my work-around, but I wanted to see if it was possible to change the native field. I appreciate your input!!
Be careful expanding text fields. We had a change slip through a backdoor, extending a text field to 750 characters. Now, most users complain about the effect this had on portlets and reports - the one/few hurt the many.
Better to use notes or sub-object lists. Eventually, even a 2000 character text field will get filled - then what? We tell users to cut the oldest content and paste it to Notes.
So, they get to the better solution, eventually - better sooner (using smaller text fields) than later.
Also, once extended, there is no way to shrink an attribute to a smaller character limit - except by deleting the attribute and recreating with a smaller value.
One can have an unlimited number of Notes, and/or an unlimited number of sub-object instances - much better than huge text fields.
I also find that some end users want to add a novel to a description field. The information in the fields should be Clear, concise, and to the point. unnecessary information could be added to another field that you could create called "Detailed Description" or an attachment field.
Totally agree. Thanks, Michael!
Yeah I like the idea of just an additional "Detailed Description" since that doesn't have to affect all your downstream MI usage... the trick (which I've often failed at) is convincing those pedantic- key-users that 2 fields are better than one (in this case!)
That was the challenge that I had in the past. It came down to the discussion that I had with them.
"You can have the field by the end of the month at no cost, or you can wait until your request makes it onto next years road map and there is a cost associated with it. Please remember that if we extend the field length, we will affect a number of reports and you will have to pay for all the report updates as well. This will also extend the development timeline. You might see the change at the end of next year or possibly the year after if your change gets bumped."
They went with the end of the month solution.
Good to know!! Thank you, Dale!
Retrieving data ...