RTC: Regular Expression Validator matching whole word
![]()
Hi Jazz community,
at the moment I have troubles creating an validator for work items. What do I want to do? I need a validator which checks that "unassigned" is not a valid entry. For this I want to create a regular expression validator which matches a whole word "unassigned". But I have a really stupid problem: I'm not able to define this regular expression. First question: which regular expressions are used? Java ones? I used different ones :p ![]() So what I need is a regex for a whole word. Any ideas? Google and Wikipedia did not help as all the things I found (e.g. \bunassigned\b) did not work Using RTC 4.0.4 Greetings, Simon
showing 5 of 24
show 19 more comments
|
Be the first one to answer this question!
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.
Comments
Simon, I would be surprised if you could configure a regular expression against filed against. The reason is that Filed against is not a regular string attribute, but of type Category.
You might have to use a JavaScript validator (as described in the Process Enactment Workshop Lab5) and use getLabel or the built in UIUID.
Thanks for that info Ralph - didn't know it as I did not have the Process Enactment Workshop before ;)
Will try to use JavaScript instead.
It is here: https://jazz.net/library/article/1093 we are looking into making it independent from RMC, but even then,reading and setting up a project to be able to just run Lab 4 and 5 should be doable. Lab 3 explains the attributes you need.
Thanks Ralph,
one morething to the JavaScript part.
As I understand this correctly it wouldn't be working within Visual Studio as it does not support JavaScript, right?
It would only work within the WebUI and Eclipse.
That is correct. As of today JavaScript works with Eclipse and Web UI and does not work with VisualStudio, the Windows RTC Shell and the Plain Java Client API
ok ... hugh problem ... any other possibilities to get a match that unassigned should not be able to choosen?
Have you tried to make the attribute required?
Hi Ralph,
this attribute is required in our company ;) As there is a value "Unassigned" by default this attribute is set all the time.
Dang. I did not consider this.
As a last option, you could create a server work item save advisor, that prevents saving the unassigned value. Code for an advisor (but for delivery) can be fond here: http://rsjazz.wordpress.com/2012/11/01/restrict-delivery-of-changesets-to-workitem-types-advisordelivery-of-changesets-associated-to-wrong-work-item-types-advisor/
The advantage of such a solution is, that it works for all clients.
Thanks Ralph,
as soon I'll find the time I will try this and report it here.
on my systems, if Filed Against is not changed from the default ('unassigned'), if get a save error![](https://jazz.net/forum/upfiles/filedagainst.jpg)
So I was not all wrong. Unsure why I was missing this. This is the default on most of the systems I work on as well.
Hi Sam,
could you please post how you did this?
In our case there is saving possible with value "unassigned" though the "Filed Against" is set as "required" attribute.
Could this be some kind of Java Scipt extension?
this is out of the box. 4.0.3 (altho I also tried on 4.0.1)
created a workitem (defect) , typed into the title and pressed Save.
the 'filed against' was shown as required ('*')..
the initial category is 'Unassigned'
with this precondition set. (default)
Hi Sam,
thanks for this but as described above, our "Filed Against" attribute is set to "required", too:
We have the little asterisk symbol within the work item mask but are able to save.
The only difference is that nobody is member in the project area. This results in getting a "permission denied" error when trying to save the work item with "unsigned" category as nobody is able to save within the project area (the root category is associated to the project area by default).
And this is what we want to prevent. We don't want the error message "permission denied" as nobody of our developer knows to set this in contract with the category.
ok - I checked it again.
With eclipse we get the needed behaviour (not the same you get but it's good enough):
But in the WebUI the error message the user gets is still "Permission denied":
I only checked WebUI before - so sorry for this :)
So I think this is at least an enhancement request that the WebUI should give the same information as eclipse.
OK guys ... one more information.
Eclipse throws both error messages:
1) permission denied
2) files against not set
WebUI seems only to display the first error: permission denied.
2nd appendix:
Visual Studio has the same behaviour as the WebUI.
Enhancement is open:
attribute is reuired - error message should give user friendly information
I don't see a "Required Properties' precondition in my OOtB 4.0.4.
is yours an upgrade from a prior release?
notice mine is 'Required Attributes for Type and State'
I see the same correct message in the web ui
Yes, we upgraded from many prior releases (3.0, 4.0, 4.0.1, 4.0.3) to 4.0.4.
But preconditions should be the same, or?
We're using the Scrum Template with minor changes.
I assume you'll get just one error message as you are able (permission granted) to save within the associated team of the "Unassigned" cat - right?
same, but the advisor name and function changed at 3.0.1.1 I think (we moved from 2.0.0.2 to 3.0.1.1)
check to see if the other Advisor is there..
Yes, there was a change in names and behavior. It would be worth checking.
I think those preconditions are doing the same. If I open the "Add precondition" dialog I'm not able to add the "Required Attribute" anymore but instead I'm able to add the "Required Attribute for Type and State" precondition.
If I add the "Requires Attribute for Type" precondition I can take a look at the ID within the "process configuration source" and see that both preconditions have the same ID.
This is why I think the behaviour is the same as I use the same precondition. The name is just the one of the former relase.