A repo and NPM package for Office.js, corresponding to a copy of what gets published to the official "evergreen" Office.js CDN, at https://appsforoffice.microsoft.com/lib/1/hosted/office.js.
Insert -> Upload my add-in that manifest for sideloading
Actual behaviour
Two add-ins are displayed in the file, which is very confusing.
Effectively only one of them registers custom functions, but otherwise they are in conflict with each other.
File is "poisoned" with the dev add-in for all other users, especially if it's shared one, produces inconveniences and support requests.
When someone else without the dev add-in opens the file, they will see "this add-in is no longer available" error for one of the add-ins.
Overall, very poor user and dev experience with this strange approach.
This may be related to https://github.com/OfficeDev/office-js/issues/2776 - in that case, it was not a development add-in conflicting with store add-in, but it was an org add-in conflicting with the store add-in.
Expected behavior
We'd really like the add-in to be recognized as the same instead of registering multiple times in the workbook.
In addition, we would like clear product rules around the priority of such recognition.
Proposal:
For example, "sideloaded" has priority Top, "admin managed" has priority Medium, and "store installed" has priority Low. In particular if the user has a sideloaded dev add-in registered in his machine, this version would be preferred to the store / admin managed version from the document.
At the same time, if someone with a sideloaded dev add-in opens the document that uses a production add-in from the store, we want it not to "poison" the file with the dev version. We want our clients (who share workbooks with us to troubleshoot) and the corporate exec team not to see pesky notifications about "this development add-in is no longer available".
I am not sure if any changes need to be made to the registration mechanism of the add-ins in the document, maybe they do - but we clearly want only one add-in to be loaded in these scenarios.
I don't have a clear architectural recipe for the fix, what I can only say is that the current mechanics look broken for our clients and warrant a change for better UX.
Context
This problem negatively affects the customer perception of the modern add-in framework and our new cross-platform offering.
Your Environment
Steps to reproduce
Actual behaviour
This may be related to https://github.com/OfficeDev/office-js/issues/2776 - in that case, it was not a development add-in conflicting with store add-in, but it was an org add-in conflicting with the store add-in.
Expected behavior
We'd really like the add-in to be recognized as the same instead of registering multiple times in the workbook.
In addition, we would like clear product rules around the priority of such recognition.
Proposal:
I am not sure if any changes need to be made to the registration mechanism of the add-ins in the document, maybe they do - but we clearly want only one add-in to be loaded in these scenarios.
I don't have a clear architectural recipe for the fix, what I can only say is that the current mechanics look broken for our clients and warrant a change for better UX.
Context
This problem negatively affects the customer perception of the modern add-in framework and our new cross-platform offering.