• A new HTTP Filtered value set in the child project area is not seen for picking to be the provider for an inherited field from the parent.
• And a new value set in the master will not work within the WI’s in the child.
• Neither will the existence of the value set in both parent and child helps.
• That was why an existing, but unused, value set is used for these two new attributes in PRD.

• Once set, they show up on the customized Defect form when tested in Chrome.
• A user challenged their existence on IE8.
• Their disappearance from the form was verified on my IE8 as well.
• Went to the editor Presentation of the form and the presentation of the two attributes did not show any anomaly.
• Verified with 3 other users, they had no issue with seeing the 2 attributes on the form
• Came back to my own PC, and the 2 fields magically showed up on IE8 as well.
• Verified with another user successfully.
• The original user finally get to see these 2 fields after the umpteenth close of all IE8 instances, then restart & re-login to the RTC.
• Attributed the glitch to long live browser cache.
• Unfortunately, can't do so several days later, when heard from more users and also experienced the disappearance a second time.
• Grappling for straws, after inspecting several things, and visits to the editor presentation, move the 2 attributes up a few positions  in the form.
• That seemed to bring the attributes back.
• Next day, today, checked and they were hiding again.
• Nothing worked, including moving them on the form again.
• So open up the RTC client (had been on Chrome and IE8), it worked on the client.
• Rechecked the browsers, it worked on them too.
• Was going to create two new attributes, one with short id (like forDebugOnly) , the other with long id (like com.acn.dor.workitem.attribute.forDebugOnly2), to elimane any flimsy cause possible from using the long ID for these 2 attributes.
• But found that the same value set has not been configured in the parent project area, though remembered that it has been fixed before without effect on the issue.
• Cloned the value set from Child to Master/Parent.
• That seemed to have brought the fields back twice: Once when going in about to create new debug attributes, the second when the parent value was mysteriously and inadvertently reverted.

§  Most of the time it picks up the value set from the child: When they showed up.

§  But at times it tried to pick up the un-configured value set from the master: That was when they disappear.

§  There are certain actions, or sequences of actions, and maybe with some dependence on elapse time that trigger the switch of dependency.

§  Note that the value set get an identical unique ID on both parent and child: don’t know if they are further qualified by project area.

§  And the failed value set probably created conflicts that the RTC handled by not showing them rather than showing them with empty dropdown.

Note that: we have used internal HTTP filtered value sets (RTC source controlled) for several other attributes with no issue of disappearing. Existing value sets (prior to the inheritance break) are used. We have not done an exhaustive check to verify that all value sets (we have close to 100 in total) in use are configured on both parent and Child.

If it is indeed due to this consistency, then anybody know why and when the dependency on parent or child get switched. And IBM folks, pls do tell if this is intentional, for what purposes ?