Probably a silly question but I'm unable to find an answer.
I have to add a field in iTop.
The data is numeric, integer, and values are from -20 to 999
I put a AttributeInteger field, and I'm unable to control input data.
Also, iTop doesn't let me put a negative value, and send back a cryptic message about a mandatory field not set.
(That particular point seems the same as the opened bug here : https://sourceforge.net/p/itop/tickets/1469/ - And, for that, I agree with Hipska, as an integer in mySQL / MariaDB is a number between -2^31 and 2^31 -1, it seems logical to me to be able to store negative number from the iTop interface. OTOH, if, for you, an integer is only a positive value, I think that the explanation of the iTop'ish Integer should be on the XML reference page, just for clarification )
I suppose I could do the job using an AttributeString and a nice ValidationPattern, but it seems strange to me that iTop is not able to check number validity ?
What is the more 'iTopish way' to deal with such a question ?
Thanks,
Pascal
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately the current validation pattern on the AttributeInteger is "^[0-9]+$" which means that there cannot be a "-" before the numbers... A bit strange I agree! It might event be a bug IMHO (@cisou)
On the other hand, the AttributeDecimal seems to accept negative numbers based on its validation pattern "^[-+]?[0-9]\d{0,$iNbIntegerDigits}(.\d{0,$iPrecision})?$", so you could use this type and say that you want a precision of 0 ?
Still not a perfect / elegant solution I'm affraid. IMHO:
- The best way would be to fix iTop so it accepts "-" on AttributeInteger
- A fast and clean way would be to develop your own SchirrmsAttributeInteger which inherits from AttributeInteger and only overloads the validation pattern.
(Note: Glad to see you there!)
Hope this helps,
Guillaume
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Pascal,
It's a quite old limitation, you're right! I should have added it to the XML definition sooner. It is done now.
For negative integer I used myself a Decimal as proposed by Guillaume, so it's a working solution. You don't need such complex validation patern as you have XML tags to specify
<digits>3</digits>
<decimals>0</decimals>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for your fast answer. And thank for the doc update :) We'll probably go on decimal, in that case.
(I'm not often here, but the good news is that we are working much more on itop here -that means : I'm not any more the only one knowing how iTop works :))
Pascal.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the answer. I went trough that page during my research, but, even if this is an 'ultimate answer', I find the solution a little too big :) I was thinking to something more obvious in the datamodel definiton.
BTW, we did test today with a decimal and it seems good enough for us, at this point.
Thanks to you all,
Pascal
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
Probably a silly question but I'm unable to find an answer.
I have to add a field in iTop.
The data is numeric, integer, and values are from -20 to 999
I put a AttributeInteger field, and I'm unable to control input data.
Also, iTop doesn't let me put a negative value, and send back a cryptic message about a mandatory field not set.
(That particular point seems the same as the opened bug here : https://sourceforge.net/p/itop/tickets/1469/ - And, for that, I agree with Hipska, as an integer in mySQL / MariaDB is a number between -2^31 and 2^31 -1, it seems logical to me to be able to store negative number from the iTop interface. OTOH, if, for you, an integer is only a positive value, I think that the explanation of the iTop'ish Integer should be on the XML reference page, just for clarification )
I suppose I could do the job using an AttributeString and a nice ValidationPattern, but it seems strange to me that iTop is not able to check number validity ?
What is the more 'iTopish way' to deal with such a question ?
Thanks,
Pascal
Hello Schirrms,
Unfortunately the current validation pattern on the AttributeInteger is "^[0-9]+$" which means that there cannot be a "-" before the numbers... A bit strange I agree! It might event be a bug IMHO (@cisou)
On the other hand, the AttributeDecimal seems to accept negative numbers based on its validation pattern "^[-+]?[0-9]\d{0,$iNbIntegerDigits}(.\d{0,$iPrecision})?$", so you could use this type and say that you want a precision of 0 ?
Still not a perfect / elegant solution I'm affraid. IMHO:
- The best way would be to fix iTop so it accepts "-" on AttributeInteger
- A fast and clean way would be to develop your own SchirrmsAttributeInteger which inherits from AttributeInteger and only overloads the validation pattern.
(Note: Glad to see you there!)
Hope this helps,
Guillaume
Hello Pascal,
It's a quite old limitation, you're right! I should have added it to the XML definition sooner. It is done now.
For negative integer I used myself a Decimal as proposed by Guillaume, so it's a working solution. You don't need such complex validation patern as you have XML tags to specify
<digits>3</digits>
<decimals>0</decimals>
Hi Guillaume an d vdumas,
Thank you for your fast answer. And thank for the doc update :) We'll probably go on decimal, in that case.
(I'm not often here, but the good news is that we are working much more on itop here -that means : I'm not any more the only one knowing how iTop works :))
Pascal.
You could even enhance it further by using the CheckToWrite() method ( https://www.itophub.io/wiki/page?id=latest%3Acustomization%3Acheck-to-write ) to do further validation of the value.
Hi Jeffrey,
Thanks for the answer. I went trough that page during my research, but, even if this is an 'ultimate answer', I find the solution a little too big :) I was thinking to something more obvious in the datamodel definiton.
BTW, we did test today with a decimal and it seems good enough for us, at this point.
Thanks to you all,
Pascal