MAM 7.6.1.2:

It looks like it's possible to have YORN attributes that are optional (required=0):

OOB:


In order to create an optional YORN field, I would need to update the MAXATTRIBUTECFG table through the back-end (set REQURIED to 0). This would be done to a pending change that has not yet been applied through db config. I've done that in the past, and as far as I can tell, it seemed to work ok in Maximo.

Question:
Is anyone aware of known issues with optional YORN attributes? I know it wouldn't be supported, but I'm ok with that. This is just a hypothetical question.
#AssetandFacilitiesManagement
#Maximo

I know sometimes out of box this is set this way but I don't think it should ever be done. A checkbox (or now toggle button) in Maximo can only represent 2 states (yes outside of Maximo there are products that support 3 states for a checkbox). It's either on or off, null has no way to be represented. If somehow you get a null value in the database (such as a backend insert) it will cause issues. By making it required it's not possible to get a null value in the database. 

As an example, inspections added some YORN attributes for tracking whether it's an audio guided inspection form (along with a couple of other YORN fields) and during the patch that added these attributes they were set to not required and did not get set. You therefore couldn't revise the inspection form on any records pre-upgrade because Maximo would try and validate the boolean and null isn't valid. You had to backend set these values so it could operate as expected. This bug wouldn't have occurred if it was marked required because the scripts to add the field would have set the values on the existing records. 

------------------------------
Steven Shull
------------------------------

Some related thoughts:

1. When an optional YORN field is displayed as a checkbox, you can't visually tell the difference between NULL and N. They look the same. For example, the first WO in this list has a value of NULL, not N.


2. If you wanted to filter a YORN for "is null" via the list view or Advanced Search, how would you do that? I wonder if it's not possible, other than through a WHERE clause.

3. Users could get unexpected results when filtering on an optional YORN field. Records with NULLs would be inadvertently excluded.


Original Message:
Sent: Tue November 30, 2021 09:25 AM
From: Steven Shull
Subject: YORN attribute that is optional (required=0)

I know sometimes out of box this is set this way but I don't think it should ever be done. A checkbox (or now toggle button) in Maximo can only represent 2 states (yes outside of Maximo there are products that support 3 states for a checkbox). It's either on or off, null has no way to be represented. If somehow you get a null value in the database (such as a backend insert) it will cause issues. By making it required it's not possible to get a null value in the database. 

As an example, inspections added some YORN attributes for tracking whether it's an audio guided inspection form (along with a couple of other YORN fields) and during the patch that added these attributes they were set to not required and did not get set. You therefore couldn't revise the inspection form on any records pre-upgrade because Maximo would try and validate the boolean and null isn't valid. You had to backend set these values so it could operate as expected. This bug wouldn't have occurred if it was marked required because the scripts to add the field would have set the values on the existing records. 

------------------------------
Steven Shull
------------------------------

So this is kind of interesting... back in the 4.1.1 and 5.x days we in the PS group at MRO called this the YORNM field.  The field was ALN 1 and could in fact be null.  Usually it had a domain value list of {Y,N}. Sometimes folks put in an M. (Yes,No, Maybe).  The whole idea being that sometimes there was a case that the attribute was neither Yes nor No.  (Think Quantum Mechanics for a moment and the idea is less far fetched than it first sounds.)

For the vast majority of cases however, it is to a certain extent, illogical to have a boolean field be null;  (as for programmatic reasons as Steven points out) is is also a bad business practice for MBO validation purposes.  With all that said, the required checkbox has never been required when instituting a boolean field.  That only means that when you try to insert a record through the backend it will not insist on a value. If you have a default value set then it will insert the record with that default value. So if you try to insert via the MBO (i.e. a MIF load or other API call,) you will get the default value inserted and all is well.

But lets go back to a fundamental question:  What is your business trying to accomplish with a null value on an otherwise boolean field that is binary.  It is either Yes or No, i.e.. 1 or 0.  So what case provides a valid Null?  When you solve that you can then decide whether or not you really need to use a YORN field and whether or not you want to go through all the issues associated with this scenario.

Hope this helps.

------------------------------
Bradley K. Downing , MBA
Solutions Engineer
IBM
Bakersfield CA
------------------------------

Thanks Brad. I had wondered if an optional YORN field in a view could solve this issue:
Ad-hoc report filling in gaps on right side of join incorrectly

Edit:
But on second thought, that issue might be with the DEFAULT VALUE, not the REQUIRED field.



Original Message:
Sent: Tue November 30, 2021 10:50 AM
From: Bradley Downing
Subject: YORN attribute that is optional (required=0)

So this is kind of interesting... back in the 4.1.1 and 5.x days we in the PS group at MRO called this the YORNM field.  The field was ALN 1 and could in fact be null.  Usually it had a domain value list of {Y,N}. Sometimes folks put in an M. (Yes,No, Maybe).  The whole idea being that sometimes there was a case that the attribute was neither Yes nor No.  (Think Quantum Mechanics for a moment and the idea is less far fetched than it first sounds.)

For the vast majority of cases however, it is to a certain extent, illogical to have a boolean field be null;  (as for programmatic reasons as Steven points out) is is also a bad business practice for MBO validation purposes.  With all that said, the required checkbox has never been required when instituting a boolean field.  That only means that when you try to insert a record through the backend it will not insist on a value. If you have a default value set then it will insert the record with that default value. So if you try to insert via the MBO (i.e. a MIF load or other API call,) you will get the default value inserted and all is well.

But lets go back to a fundamental question:  What is your business trying to accomplish with a null value on an otherwise boolean field that is binary.  It is either Yes or No, i.e.. 1 or 0.  So what case provides a valid Null?  When you solve that you can then decide whether or not you really need to use a YORN field and whether or not you want to go through all the issues associated with this scenario.

Hope this helps.

------------------------------
Bradley K. Downing , MBA
Solutions Engineer
IBM
Bakersfield CA
------------------------------