[SOLVED] Extending "Required Attributes For Type and State" Advisor
Accepted answer
please have a look at https://jazz.net/library/article/292 how behavior is supposed to work.
If you configure operational behavior for several roles, the operational behavior first found is used. There is no "Inheritance" mechanism. The purpose is to be able to configure different behaviors for different roles. E.g. the "ComponentOwner" role could be able to deliver, while other roles need an approval. So, if you configure another role in the grid, that effectively overrides the behavior for this operation for this role.
2 other answers
Comments
thanks. My problem is designing the UI, not the mechanics of making it work.
1 vote
@sam It´s my problem too. I mentioned the getting starting tutorial, to prepare other people that can contribute with us. But for sure the most problem is extensibility. And for this point I think we can start a project to developer a osgi framework focused on rtc tools. May be a plugin with many archtypes using method factory pattern, and the end user can extend with this hook methods. So It´s just a little idea to start in the case if we can not find nothing similar or better. What do you think about it. best regards.
my comment re the UI was I have trouble figuring out what UI element to use when, and how it lays out and operates..
I HATE placing things on the panel. the little space, do you click of scroll, up/down left/right the darned tab order, etc..
and writing all the little handling routines to implement data filters.. when was the last new data type? these should all be standard filter/mask by now. (reg expression matching at minimum).
and one install thing.. its a data model, why can't the data model be delivered from the server, so there is only ONE package to install in ONE place.
ok, rant over..
2 votes
me too ;) Tell me more about the idea of "the data model be delivered from the server" and "ONE package to install in ONE place" . Suppose I want to solve your problem.
I am all with you here.
I try to avoid doing UI stuff in Java. I avoid aspect editors.
And I would agree it would be great if there would be only one place to deploy - on the server. Therefore I try to do server based behavior only, if at all possible.
Sorry for the multiple edits - I keep hitting CTRL-Enter to create a new line, but that saves the post.
1 vote
this is partly why we don't have the full admin UI on the web client. the plugin UI is deployed on the eclipse client.
describe the UI as a dialog in XML.. thats what it is..
when the client opens (regardless of where), the aspect editor base code retrieves the UI description from the server (a new service call), and then like a dialog editor base, populates and executes the dialog. returning a data structure to the client when the dialog closes.
1 vote
Sam, please note that with 4.0.5 we have the first attempts to be able to configure operational behavior in the Web client. Please see: https://jazz.net/downloads/rational-team-concert/milestones/4.0.5RC1?p=news
I am not sure what the plan for custom behavior will look like, but there is an attempt being made for the ootb operational behavior.
I hope to see other stuff, such as attribute customization with Java, can also be deployed solely on the server and work for all clients.I don't have the slightest idea how that could work, but it would certainly make things so much easier.
2 votes
Very nice @Ralph. Thanks ;)
thanks Ralph.
Comments
sam detweiler
Nov 04 '13, 9:06 p.m.Unfortunately, the product provided advisors are not 'extendable'. You could extract the source and build your own version with your unique identifiers. (I have done this).
1 vote