For reporting purposes we would like to have REST methods to retrieve metadata about objects in bulk. Right now we have to retrieve the list of objects first, then get metadata about each of them. This is definitely a very inefficient way to build reports. Essentially, would like a REST method that allows to query for the following objects AND specify fields we want to see in the query results, such as created and last modified dates, author, number of items (in a list), size, permissions, etc. We believe that having such REST methods for Sites, Lists and libraries, and List items and documents can make reporting more efficient, considerably enhance solution performance, and minimize unnecessary load on SharePoint.

One thing that I miss a lot is to have the ability to write .Net code for Excel with the simplicity of the VBA editor. VSTO is great for IT professionals but impractical for most advanced Excel users as most users are not privileged to install applications directly in large companies (so distributing an excel based model internally is impossible, and non-advanced users would not touch a spreadsheet which is too complicated to set up).

The way VBA works is brillant, we have a single self contained spreadsheet that requires no installation, has no dependencies, and for which creating user-defined functions and scripts is dead simple. Users can send it by email and it works on everyone's machine with no packaged to install.

But this language is almost 15yrs old and lacks many of .Net features. It would be great to have .Net projects (like we have VBA Project) and be able to open a simplified Visual Studio-style editor from Excel to add code to the spreadsheet (or record macros, still the best way to excel user to do their first step into programming). In the firm I work at, it is very common to have spreadsheets that connect to databases or process files, send emails or makes complex calculations for which the VBA syntax is really clumsy.

When the user closes the web add-in task pane, the web add-in is terminated for that workbook with no warning. I currently see at least four distinct issues:
- any in-progress operation may be interrupted with unpredictable results
- The add-in’s Excel event processing and handling is terminated. So, there is no longer any reaction to user gestures such as editing a cell or changing the selection
- The user steps needed to re-open the task pane (to re-attach the add-in really) are non-obvious for the average user
- If the user does discover how to re-insert the add-in, the add-in starts from scratch and runs all startup code as if the workbook had just been opened. So, the add-in cannot continue where it left off. In our use cases, this situation can result in user data loss

Our #1 ask here is to keep the add-in running when the user closes the task pane. Just hide it. The add-in should continue to receive Excel events and be able to execute add-in code. The button to display the add-in task pane should simply un-hide the add-in (and not re-load it from scratch).

Perhaps you can introduce the concept of an application-level web add-in (Office.js) as already exists in the VSTO architecture.

Barring this, please warn the user that closing the task pane terminates the add-in and all of its functionality.

Or, provide an event that we can use to warn the users and allow them to cancel.

Thank you