5 Replies Latest reply on Feb 4, 2020 5:15 PM by Nicolas Roome

    Investigating the possibility of creating custom relationship types

    Nicolas Roome
      Share This:

      I'm creating this post here so I can provide some updates and capture some interest from the community on the need/desire to have more relationship options than what is currently available.

       

      There are a few relevant ideas about this (and probably way more through the years):

      Custom Relationship Manager

      Re-design Relationships and Link Controls (encompasses most other relationship/link control idea out there) - FP12

      Ticket/Solution Relationship

      Service/Solution realtionship

       

      I'm trying to see if I can make this work.

       

      Out of the box FootPrints has 61 relationship types. While this may seem like a lot, you can "run out" of them. For instance, if I want to link a contact to a ticket, I use the 'Ticket/Contact' relationship. But if I want to link a second "different" contact, (such as tracking the difference between the person submitting the issue, and the person having the issue.. or a ticket where I was to track an HR complaint.. the person lodging the complaint and the person whom the complaint is about).. Well you can't really do that using the address book because there is only 1 ticket to contact relationship (called 'Ticket/Contact') and to do this you'd need 2.

       

      Another scenario is where I want to link an Accounts Payable ticket to an Accounts Receivable ticket. Sure not a typical scenario, but what do you do? Well, you need a ticket to ticket relationship. Here there are many choices: RelatedTickets, Related Tickets (Dynamic), Master/Subtask, Incident/Problem, Service Request/RFC, etc etc. The thing is, the name of the relationship (such as Incident/Problem) may not match the scenario you are designing (Accounts Payable to Accounts Receivable). So you can get limited to the relationships available.

       

      There are some creative ways to get around these limitations.. use relationship names that don't make sense, duplicate fields in the address book..

       

      So I'm going to test out some theories and ideas I have to see if I can make this work, while we wait for the above ideas to be implemented by BMC. Similar to what I've done in the past, see here: New processes being developed, for those who are interested

       

      Stay tuned and feel free to chime in with some interest and feedback.

        • 1. Re: Investigating the possibility of creating custom relationship types
          Nicolas Roome

          I've found two things so far:

           

          1) I was able to identify areas in the database which store the relationship information (19 rows across 4 different tables). Not sure if I found it all, since I injected data to create a new relationship and FootPrints didn't take it. This leads me to believe I didn't find all the data.. or, hopefully not, that relationships are hard coded into the FootPrints code, and not just the database.

           

          2) I took an existing relationship in the database and renamed it. This caused FootPrints to generate an Unexpected Error. This somewhat solidifies that either I didn't get everything, or that relationships exist in the FootPrints code in addition to the database.

           

          I'll keep digging.

          • 2. Re: Investigating the possibility of creating custom relationship types
            Jacque Donald

            Nick, I can tell you we would DEFINITELY benefit from more relationships and the ability to rename them. For us it gets 'crowded' after time due to the many records in the relationship and over time, the performance deteriorates. We can definitely archive, but with limited relationships, we are often left with not many or no choices at all to segregate things we do not want to query in business rules, because we cannot remove the items from the relationship as we still require the linking to remain intact for our business processes here. This has honestly been one of my biggest gripes about FootPrints, this feels like one of the few things that make large scale growth a serious challenge with this application and for its long term stability as things do grow on our end.

            Following this to stay updated, if we can offer any insight on our end, I am willing to provide it to help this effort.

            • 3. Re: Investigating the possibility of creating custom relationship types
              Wayne Johnson

              It's like you read my mind (kind of), I came across this yesterday and it was very frustrating. I have created a service delivery catalogue, and we have 3 different contacts against each catalogue entry, all 3 work for the company but I can only have 1 link to AD in the link control.

               

              I must admit I started off naive and created 3 of each of the first name, last name and email and assumed I could map them in the link control.......nope only 1 AD contact, frustrating as you could now end up with different spellings and numbers etc.

               

              Having the ability to have multiple contacts would save a lot of headache.

              • 4. Re: Investigating the possibility of creating custom relationship types
                Nicolas Roome

                Well, I was able to partially rename a relationship. Still feel like I'm missing some information, but as far as I can tell the only data files which contain references to the relationships relate to the mobile interface. It could play a part overall, not sure.

                 

                As far as the database is concerned, I'm feeling confident I have all the entries since I found the same number of data entries in the installation files.

                 

                Still, best I can do for now is rename the relationship "ends" but not the name itself.

                If I change the name itself, FootPrints throws an error:

                 

                [...]

                Caused by: java.lang.NullPointerException: Can't find LinkTypeDefinitionVersion with id[2]

                [...]

                 

                ID 2 being the ticket/contact relationship.

                • 5. Re: Investigating the possibility of creating custom relationship types
                  Nicolas Roome

                  As far as I can tell relationships are not hard-coded in FootPrints except for the mobile app.

                   

                  Here is what I've found so far:

                   

                  And an example relationship I tried to create, but FootPrints does not see it:

                   

                  I've noticed a relationship between the defn_id and the defn_ver_id... They either match (as in the first screenshot), or they are 10000 apart, as in the second screenshot. Not sure this is actually a requirement though. Also, all defn entries start the defn_name with 'linkType'. Not sure if this is required.