Setting 'Abbreviated Name' overrides the customer name

[ichilton]

We have a few members with long names and a well known abbreviation.
e.g: Something & Something may be known as S&S or SSISP.

There is an 'Abbreviated Name' field in IXP Manager - the documentation describes it as exactly what we want:

The Name field is the customer's name as you/they typically want it to appear in IXP Manager. It is not necessarily their full legal entity name (that goes elsewhere). The Abbreviated Name is a shorter version of the name that is used in space constrained areas such as graph labels.

However, that isn't the behaviour I see when trying to use it.

Not sure if this is historic / our data, or standard, but all of our abbreviated names are the same as the name. If I changed abbreviated name to say SSISP using the example above, rather than it just showing the abbreviated name when a shorter version is required, it completely overrides the name - the main title on the customer overview page changes to the abbreviated name and even worse, the full name is not even shown anywhere on the overview page anymore - the abbreviated name is use in the title and then still shown as a field.

This doesn't appear to be a skinning issue as taking a quick look at the code, at a glance, it looks like it's only using abbreviated name:

IXP-Manager/app/Models/Customer.php

Line 816 in 53333e4

public function getFormattedName( $fmt = null ): ?string

        if( $this->type === self::TYPE_ASSOCIATE ) {
            return $this->abbreviatedName;
        }

I think (and the documentation agrees), that it should still show the main name, but use abbreviated name only where there are space constraints (and the reason for setting it and finding it in my case is I want that data to be available via the API for use with automation).

Ideally, it would show the title as something like: "$name ($abbreviated_name)" (eg: "Something & Something (SSISP)") or even better, use name for the title and show a sub-title of the abbreviated name if it's set.

That in place, I think data wise, the abbreviated name field should be blank except when explicitly relevant/set - that avoids lots of "if $abbreviated_name != $name" statements in views.

Thanks!

Ian

[barryo]

For convenience below, AN = abbreviated name / FN = full / normal / standard name.

I'll dissect your email piece by piece @ichilton as I think that's the easiest way to address all your comments as well as provide some background. And we're going back nearly ten years here - an unfortunate consequence of a long-running project is the cycle where by configuration evolves through increasing levels of flexibility (and complexity), before returning the restrictive and simple implementation. I think we're at peak flexibility now which is why I push back a bit on requests to add more configurability for fairly low impact elements. Anyway, I digress - to the issue at hand:

The Abbreviated Name is a shorter version of the name that is used in space constrained areas such as graph labels.

There's some key words here that are screaming at me - such as graph lablels - which makes me think this may be one of the few explicit uses of AN to date. Happy to look at any requests / PRs to use it in other places. But please read on - much more on this:

Not sure if this is historic / our data, or standard, but all of our abbreviated names are the same as the name.

The original migration would have set AN = FN. Then, when added members via the UI, once you focus out of the FN field, it will auto-populate the AN field to be the same. See end of response for more info.

If I changed abbreviated name to say SSISP using the example above, rather than it just showing the abbreviated name when a shorter version is required, it completely overrides the name - the main title on the customer overview page changes to the abbreviated name and even worse, the full name is not even shown anywhere on the overview page anymore - the abbreviated name is use in the title and then still shown as a field.

Per feature request in #88, we made the display of customer name's configurable. See this config option which is also the default and I have just now pushed 1c414da to make it configurable without changing the static config file.

I also added a section to the documentation on this.

As you can see, the default is to use the AN - this dates from nearly 10 years ago, I have no specific memory of the reasoning.

Then, where we haven't made any specific judgements about using FN or AN or space constraints, we call the customer's getFormattedName() function which uses this config option.

at a glance, it looks like it's only using abbreviated name:

That seems to be true for associate members only. Not sure what Yann's take was on that or if it was in the original code he ported from. Will need to look into it - again, for associates only.

I think (and the documentation agrees), that it should still show the main name, but use abbreviated name only where there are space constraints

So, the way this should work is:

1. in non-space constrained areas - and where no specific display requirements or constraints exist - we should use the configured formatting.
2. where a requirement / constraint exists to use the full name (e.g. members list where the member expects / requires their proper name), use the FN.
3. in known space-constrained areas (e.g. graphs) use AN.

I don't really intend to audit every use before closing this issue - happy for anyone to do it and reopen with a list of incorrect uses or provide a PR. Otherwise we'll just catch them as we go. Perhaps @ichilton, the explanation on the config option will solve your immediate issue anyway?

Ideally, it would show the title as something like: "$name ($abbreviated_name)" (eg: "Something & Something (SSISP)") or even better, use name for the title and show a sub-title of the abbreviated name if it's set.

Sorry, I don't like this. I think having two versions of the name is just overkill given the 1/2/3 use-cases set out above. Let's just try and use the appropriate form in the appropriate places.

I think data wise, the abbreviated name field should be blank except when explicitly relevant/set - that avoids lots of "if $abbreviated_name != $name" statements in views.

This is a coin-toss. If it's empty/null you're just reversing the check. If, as a rule, both are set, you can just use the appropriate one as required without any if/else; I think this is simpler. For the general case, we use a function for the most part and don't need to think about it.

Hope that helps.