Geoffrey Delmee Prodware Technical architect

Having to turn environment in maintenance mode to manually set the license configuration is not as safe as automated import.

Being able to get the right license configuration set and import it to the environment (as a step during environment creation for example) may ensure licenses are set the right way in all environments.

Having a large deployment with several countries or regions implies difficulties to manage users.

It should be possible to have several security administrators who manage different areas (one or several countries).

One way to do so could be when 'Security administrator' role is set to a user on one or several companies, he can only grant roles for the set of companies he is allowed.

Once an asset has been deployed in an environment, it is no more possible to delete it. Even there is a new "version" (i.e. ISV package or ISV license codes), it is not possible to delete the "old" one.

Being able to delete assets even if have been deployed will allow to keep a clear view of the assets.

Following those two ideas:

- "Upload a new version" in project asset Library

- Being able to delete assets in asset Library

Once versioning in project asset ibrary is available, "merging" different assets as different versions of the same asset will allow to clarify the asset view.

Also, it will prevent to deliver an "old" version as only the current version of an asset can be deployed.

Finally, it will ensure the deletion of an asset version as a new one is available to replace it. (i.e. nightbuilds which can polute the asset Library view).

In order to continue the evolution to C#-like syntax, can you implement the foreach?

I totally understand we can't modify a standard mandatory field to set it not mandatory anymore. But we need sometime to set a standard field as mandatory regarding the customer's processes. By now, we can't trigger this property on the field. So we have to implement it in the table methods and manage it in every form. Being able to set a non mandatory standard field as mandatory could be a nice improvement.

By now, to customize the Power BI Embedded report, we need to disable the tab and recreate it in the form extension and reimplement the same code as the standard but with another resource name. I just propose to add a replaceable protected method retrurning the resource name then we just have to replace this method. Please consider to vote up if you find it usefull. Hoping it could make it for the next release. It was a connect request raised in december 2017: https://connect.microsoft.com/site1321/Feedback/Details/3144665