There are system fields:
As I understand these fields are of type double. TFS does not allow you to enter letters into these fields.
My problem is that TFS allows you to enter a dot (.) or a comma (,) in the fields. But if you enter a comma (,) in the field, TFS deletes it after saving the form. For example, the number 15,50 will be converted to 1550.
I understand that this can be partially corrected by the Windows localization settings, but this option does not work. does not provide a 100% guarantee.
The documentation found that you can use pattern matching, but this only applies to fields of type string (https://learn.microsoft.com/ru-ru/vsts/work/customize/reference/apply-pattern-matching-to-string-field).
How can I check the value in the field so that when I enter 15,50 I get 15.50 or an error when saving?
Used version of TFS 15.117.27024.0.
Unfortunately the feature is not supported for now.
You can only set that with dot (.), but it will remove the 0 if the last bit is 0, that means you can only get 15.5 but not 15.50.
And there isn't a rule to match the condition which contains a comma (,) in the fields (See Assign conditional-based values and rules). So, we also cannot set error when saving.
Actually there's already a user voice here to suggest this feature, you can go and vote it up to help achieving that in future.
Related
I am trying to write a JIRA query to query a bunch of defects. The problem I am having is that if there is a JQL keyword in the list of defects I am querying, the entire query fails and spits out the following error:
JiraError HTTP 400 - text: Error in the JQL Query: 'update' is a reserved JQL word.
You must surround it in quotation marks to use it in a query.
My query:
jira.search_issues( 'key in ({})'.format(','.join(defects))),
validate_query=false,
maxResults = MAX_JIRA_RESULTS )
This fails when a defect contains the word: 'update'. Now it is a bad data error, but I want to make sure the query is tolerant to malicious input.
Now the only way I can think of to make sure this bug never happens again is to make sure each defect that contains a JIRA keyword has that keyword escaped. This is obviously pretty tedious and is subject to fail if any new JQL keywords are added.
So is there a better way to do this other than escaping each JIRA keyword I find in my string? Additionally, is there an easy way in Python to get the JIRA keywords?
Thanks!
First of all, you can quote anything that you pass to that particular query, so you don't have to care about what is a reserved word or not. For example, this works:
key in ("abc-1","def-2")
If you were to substitute the word "update" in there, it would eliminate the specific error you are complaining about...but, unfortunately, you'd get another one: The issue key 'update' for field 'key' is invalid.
Luckily for you, there is a better solution. Your question indicates that you are working with issue keys. JIRA issue keys are always of the format:
<PROJECT>-<ISSUENUM>
where the format of PROJECT is explicitly defined by JIRA, namely:
The first character must be a letter,
All letters used in the project key must be from the Modern Roman Alphabet and upper case, and
Only letters, numbers or the underscore character can be used.
Instead of blacklisting keywords, you can instead whitelist anything that matches the issue key regex and reject everything else.
Note that while it is possible for the JIRA system administrator to change the project regex format outside of those guidelines, this is relatively uncommon (and Atlassian does not support JIRA running in that configuration anyway).
In EDIFACT there are numeric data elements, specified e.g. as format n..5 -- we want to store those fields in a database table (with alphanumeric fields, so we can check them). How long must the db-fields be, so we can for sure store every possible valid value? I know it's at least two additional chars (for decimal point (or comma or whatever) and possibly a leading minus sign).
We are building our tables after the UN/EDIFACT standard we use in our message, not the specific guide involved, so we want to be able to store everything matching that standard. But documentation on the numeric data elements isn't really straightforward (or at least I could not find that part).
Thanks for any help
I finally found the information on the UNECE web site in the documentation on UN/EDIFACT rules Part 4. UN/EDIFACT rules Chapter 2.2 Syntax Rules . They don't say it directly, but when you put all the parts together, you get it. See TOC-entry 10: REPRESENTATION OF NUMERIC DATA ELEMENT VALUES.
Here's what it basically says:
10.1: Decimal Mark
Decimal mark must be transmitted (if needed) as specified in UNA (comma or point, put always one character). It shall not be counted as a character of the value when computing the maximum field length of a data element.
10.2: Triad Seperator
Triad separators shall not be used in interchange.
10.3: Sign
[...] If a value is to be indicated to be negative, it shall in transmission be immediately preceded by a minus sign e.g. -112. The minus sign shall not be counted as a character of the value when computing the maximum field length of a data element. However, allowance has to be made for the character in transmission and reception.
To put it together:
Other than the digits themselves there are only two (optional) chars allowed in a numeric field: the decimal seperator and a minus sign (no blanks are permitted in between any of the characters). These two extra chars are not counted against the maximum length of the value in the field.
So the maximum number of characters in a numeric field is the maximal length of the numeric field plus 2. If you want your database to be able to store every syntactically correct value transmitted in a field specified as n..17, your column would have to be 19 chars long (something like varchar(19)). Every EDIFACT-message that has a value longer than 19 chars in a field specified as n..17 does not need to be stored in the DB for semantic checking, because it is already syntactically wrong and can be rejected.
I used EDI Notepad from Liaison to solve a similar challenge. https://liaison.com/products/integrate/edi/edi-notepad
I recommend anyone looking at EDI to at least get their free (express) version of EDI Notepad.
The "high end" version (EDI Notepad Productivity Suite) of their product comes with a "Dictionary Viewer" tool that you can export the min / max lengths of the elements, as well as type. You can export the document to HTML from the Viewer tool. It would also handle ANSI X12 too.
I'm having a strange problem that is affecting at least some of my international users of my Delphi 6 application. Here's the scenario:
My program requests status reports periodically from an external device that acts as an HTTP server.
The device sends back the status report as a response document that has a series fields delimited with the pipe character in name value pair format (e.g. - field1=-0.437).
I split the report string into the fields and then again to get each field name and numeric value.
I use StrToFloat() to convert the floating point field values in string format and assign the result of that function to a Variant variable.
This works fine on most PCs, but some of my international users are getting EConvertError's when I try to use StrToFloat() on the numeric values. Here's a concrete example of an error message from my logs:
EConvertError: '-0.685' is not a valid floating point value
As you can see -0.685 is a valid floating point number, yet I am getting the EConvertError Exception. Normally I would expect to see a comma where the decimal point is, or some other locale specific punctuation problem, but the number appears fine in this case. Also, to the best of my knowledge the external device does not even have the option to set the character set.
So what subtle nuance about Delphi 6 and international character sets might be causing this problem, perhaps related to the user's Windows XP/Win7 character settings? Note, I use standard Delphi 6 "string" cast strings throughout my program so I don't see how a multi-byte character set issue could be the root cause. Has anyone had this problem and knows what to do about it?
Your remote user's machine is expecting , for the decimal separator. When it encounters . the EConvertError exception is raised. On a machine which expects , as the decimal separator (e.g. most European and South American countries) -0.685 is indeed not a valid floating point value.
Normally I would expect to see a comma where the decimal point is, or some other locale specific punctuation problem, but the number appears fine in this case.
Your current problem is just the flip-side of the above issue. Normally, because your locale uses . as the separator, you are accustomed to seeing problems when data with , is used instead. Put yourselves in the position of somebody from a country which uses , as a separator. For them, they will be accustomed to seeing exceptions when data with . is used.
You could solve the problem by normalising the input to use the same decimal separator as the the machine locale. On a modern Delphi you could solve the problem by use the StrToFloat overload that receives a TFormatSettings parameter and explicitly specify that . is to be used as the decimal separator for this conversion. Unfortunately that facility is not available in Delphi 6.
I faced this issue for Belgian users. I also had to manually replace the '.' or ',' in the input data.
Also, if you are inserting the data into the database (sql) then, you will have to replace the ',' with '.' during insertion of the data into the database.
I have a stored procedure for SQL 2000 that has an input parameter with a data type of varchar(17) to handle a vehicle identifier (VIN) that is alphanumeric. However, whenever I enter a value for the parameter when executing that has a numerical digit in it, it gives me an error. It appears to only accept alphabetic characters. What am I doing wrong here?
Based on comments, there is a subtle "feature" of SQL Server that allows letters a-z to be used as stored proc parameters without delimiters. It's been there forever (since 6.5 at least)
I'm not sure of the full rules, but it's demonstrated in MSDN (rename SQL Server etc): there are no delimiters around the "local" parameter. And I just found this KB article on it
In this case, it could be starting with a number that breaks. I assume it works for a contained number (but as I said I'm not sure of the full rules).
Edit: confirmed by Martin as "breaks with leading number", OK for "containing number"
This doesn't help much, but somewhere, you have a bug, typo, or oversight in your code. I spent 2+ years working with VINs as parameters, and other than regretting not having made it char(17) instead ov varchar(17), we never had any problems passing in alphanumeric VIN values. Somewhere, and I'd guess it's in the application layer, something is not liking digits -- perhaps a filter looking for only alphabetical characters?
I've got an application that bridges our help desk system with TFS (one way from Help Desk to TFS). When I create the work item in TFS, in some situations I'm getting an "InvalidCharacters" validation error.
The field I'm using is the standard "Description" field, which is defined as "Plain Text" in the Work Item definition.
This is only happening on one record, so I'm sure it's the data, but I can't figure out what character is being considered to be invalid. Is there any guidance on what will trigger the InvalidCharacters validation on "Plain Text" fields?
It looks like this field is unable to display the extended ASCII characters. There was an a with an accent grave (à) in the string I was trying to save.
-- EDIT --
This actually became even more frustrating. The character representation when I did a ToCharArray() was "à", however, when I finally found the spot in the string where it was bombing, the actual character was a single-character ellipses (...). Which was probably caused by someone copying and pasting from Word into our help-desk system for comments.
My ultimate resolution was a brute force spin through the char array, replacing any character that had an int value of greater than 127 with something else (in my case, a question mark).
A ‘string’ field is invalid if it contains control characters other than newline, carriage return, and tab or if it contains mismatched surrogate characters. Longtext fields (like plaintext) accept everything except mismatched surrogate pairs. Make sure your copy/paste is resulting in Unicode being pasted in.
You can use a Regex function to compress all white space down to a " " character, such as this:
Regex.Replace( text, #"\s+", " " );
Although that actually strips more than you technically need to, since it takes out newline, carriage return and tab too.
Hope this helps!