Bug alert: The Zombification Attribute

By Max Ranzau
Will code C# for brrraaaaaaiiiins!

 

From The Brrrraaaains Dept. Although the title might sound like a weird crossover episode between Big Bang Theory and The Walking Dead, I had a super scary experience with Service Store this week. All of a sudden people attributes had disappeared from a client development environment and everyone was biting their nails the problem would propagate into production. Even the built-in People Attributes; Security Questions and Answers, had disappeared from all users when you went to their Attributes tab. What was even worse; services were failing left and right – specifically those which used any reference to #Subscriber(personattribute) or #Requester(personattribute). Looking directly into the OR_PeopleAttributes table, via SQL Studio I could see my attributes were still intact, alas something was making the ServiceStore act all gnarly and puke dayglo, while everything else seemed to work normal.

At this time of writing, I have only experienced this problem with the latest ServiceStore 2015 FR2, Update 2 AKA (8.2.2.0). I do not know if earlier versions of Service/IT store are affected. And yes, this has been reported to the Merry Men of RES Support. You’ll probably notice a new KB article over the next few days until engineering devises a fix for this.

errattr

I’ll spare you the long trials and tribulations I went through to nail this bug down over the course of a night, with only a pot of coffee and Radio Paradise for company. Let’s cut to the chase:

The problem is specifically with certain People Attributes you may define: It would appear if you define a Person Attribute of the TABLE type, with more than 6 columns defined, the problem will manifest itself at some point and your people attributes will be zombified. What specifically triggers it, is not exactly clear, however I suspect it would be when a WFA (WorkFlow Action) references the attribute. I was able to manually trigger it in a new clean database by importing a buildingblock containing the offending attribute and a dummy service.

The good news is that until the software engineers fix the problem, it is relatively easy to get rid of: Go and either delete the table Person Attribute from your Data Model, or edit it down to 6 columns or less. The moment column #7 is deleted and the table definition saved, all the hidden people attributes would re-appear.

So, now we know what we’re dealing with, allow me a moment to spin my thoughts on this: The table objects were originally created to cater for MDM, like registering something a user might have more than one of, such as mobile devices, tablets etc. Typically 4-5 fields were used for Device type, Model, Carrier, Phone#, etc, thus I can only muse that more than 6 columns might never have been attempted duing test – that is until your friendly neighborhood blogging-bull came charging through the china store and created a table attribute with 14 columns.

This concludes the alert/early warning. As mentioned, RES have already been notified, so hopefully this article will be obsolete soon.

 

No Comments

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a comment

Comments are welcome as always. Just do the math below. * Time limit is exhausted. Please reload the CAPTCHA.