[7.490][BUG][CONFIRMED] using same ip give unrelavent error

utm_kid,

can't reproduce this. Can you provide more information?

Thorsten

;122530']utm_kid,

can't reproduce this. Can you provide more information?

Thorsten

Hi Thorsten ,

Pls check image ,this is on alias interface (internal additional address)

Thanks

When you try to create a new object (for example, a new host object or a new interface object) and provide an IP address that cannot be used due to a clash, the traditional Confd message system indeed gives you the generic error message "invalid object parameter", which is technically correct, just not particularly precise.  The same applies for many other cases of invalid object parameters.

Of course, it might be useful to improve the precision of various error messages.  We have already done a lot in this respect for 7.500, using the new Confd message framework, and probably, a few more areas will be converted to new Confd messaging for 8.x - maybe this one, too.  There are no final decisions yet regarding future polishing of error messages.

Ingo, I think I'd prefer that the messages an enduser sees in email and web usage should be given the highest priority. The individual admin is more likely to have multiple interruptions and complaints from users and supervisors.

That doesn't mean I think the other messages shouldn't be fixed.  For the ones that are seen only by admins, those that have provoked a contact with Astaro Support should be prioritized.  If that feedback loop isn't already in place, then I recommend taking the approach of Amazon: "Each human contact required by our customers is an indication of a systems improvement we need to make, and should be treated as such."

Cheers - Bob

I think I'd prefer that the messages an enduser sees in email and web usage should be given the highest priority.

As far as i know, if you regard development as a whole, that's already the case.
Typically, i'm not personally working on end-user messages, though. [;)]

The whole Confd message business is typically about making things easier for ASG admins.  End-users rarely see Confd messages at all.

The individual admin is more likely to have multiple interruptions and complaints from users and supervisors.

Sure.

That doesn't mean I think the other messages shouldn't be fixed.  For the ones that are seen only by admins, those that have provoked a contact with Astaro Support should be prioritized.  If that feedback loop isn't already in place, then I recommend taking the approach of Amazon: "Each human contact required by our customers is an indication of a systems improvement we need to make, and should be treated as such."

It works more or less like that:
The more people appear to be confused by something that could be polished, the higher the probability that it will be fixed quickly.

There are a few other considerations, too:
There is always a tradeoff between tiny fixes and new features, and sometimes customers get more added value from a new feature than from a bunch of cosmetical fixes.
And, last but not least, to deliver a high-quality product and maintain the quality, you always need to invest part of the work into low-level infrastructure, most of which is not directly visible to the end user.  The Confd message system is of of these cases - even one of the more visible cases of infrastructure maintenance work.  You will see even less of, say, the MiddleWare interface code cleanup done for 7.500, but you will profit from the resulting stability improvements, in the long run.

It works more or less like that:
The more people appear to be confused by something that could be polished, the higher the probability that it will be fixed quickly.

I know that happens generally, but there seems to be a need for a more-formal method of getting useable feedback from Support injected into code and documentation development.

Anyway, you'll see in the press release that I think we've seen a marked improvement in "fit and finishing" in V7.5.  A great product!

Cheers - Bob
PS The only must-fix issue I've seen thusfar: https://community.sophos.com/products/unified-threat-management/astaroorg/f/98/t/68564