The upgrade icon seems to be working fine for me, Brian. And its working fine on a number of sites I checked. Could there be a problem with your environment?

In terms of the suggestion to link via https to the image, we currently don't have the update.dotnetnuke.com set up for SSL - but it is a possibility. For now, I have checked in code for issue DNN-5616 which solves the problem by not serving the image tag if the request is running on a secure connection.

The topic of the upgrade icon behavior has been discussed numerous times over the past year. Originally it served a green checkmark icon if there was an upgrade available and a red cancel icon if no upgrade was available. This resulted in complaints because the red cancel icon is usually associated with errors. Therefore, we change the red cancel icon to an invisible gif instead.

I think the best solution would be if the image served was more descriptive. For example, if there was an upgrade available, it could display "Upgrade Available" or "Version ##.##.## Available" or something similar. The problem is that the application is used by both English speaking and non-English speaking users. If we served an image which contained English words, it would not be a truly localized solution. Now obviously it would be technically possible to serve a localized image. Unfortunately, we are not passing any information about the preferred language in the querystring to the upgrade service. Therefore, we are missing the data required to perform localization. We had considered adding this information to the querystring, but ran into a dilemma because of privacy concerns.

Anyways, as you can see there is a great deal of consideration and deliberation which goes into core enhancements. We always try to understand the impact/risk and weigh the various pros/cons to make the optimal decision. Obviously all the factors contributing to the final implementation are not always obvious when the feature is delivered. And we sometimes make mistakes - although usually they are easily addressed through a minor modification.

While this is technically correct, it is not practical because there is a limit of one URL for the "originUrl" attribute which would cause the feature to break if the user needed a different webservices URL. A significant amount of time and effort has been expended on the issue of webservices under Medium Trust and the learnings are summed-up in the Code Access Security document.

Nik

Why can't there be more OPEN communciation/discussion BEFORE implementation?

Right now it seems you have one person who has an idea and it gets implemented.   Then users complain and it is changed.    Then more discussion and it is changed.

Changing code is one thing but when you change the UI for a single functionality multiple times in a few releases....  it is never good.  

I never got the other question answered so now it is two  :)

What there should be is a UI, QA and Product Management team..      with members consisting of core, benefactors, users, etc.