Merge pull request #12475 from MicrosoftDocs/main

10/14/2024 PM Publish

powerbi-docs/connect-data/asynchronous-refresh.md

@@ -106,7 +106,7 @@ To do an enhanced refresh operation, you must specify one or more parameters in
 |`retryCount`     |       Int   |    `0`     |    Number of times the operation retries before failing.      |
 |`objects`     |    Array      |    Entire model      |    An array of objects to process. Each object includes `table` when processing an entire table, or `table` and `partition` when processing a partition. If no objects are specified, the entire model refreshes.      |
 |`applyRefreshPolicy`    |    Boolean     |    `true`     |   If an incremental refresh policy is defined, determines whether to apply the policy. Modes are `true` or `false`. If the policy isn't applied, the full process leaves partition definitions unchanged, and fully refreshes all partitions in the table. <br><br>If `commitMode` is `transactional`, `applyRefreshPolicy` can be `true` or `false`. If `commitMode` is `partialBatch`, `applyRefreshPolicy` of `true` isn't supported, and `applyRefreshPolicy` must be set to `false`.|
-|`effectiveDate`    |    Date     |    Current date     |   If an incremental refresh policy is applied, the `effectiveDate` parameter overrides the current date. If not specified, UTC is used to determine the current day.      |
+|`effectiveDate`    |    Date     |    Current date     |   If an incremental refresh policy is applied, the `effectiveDate` parameter overrides the current date. If not specified, the current day is determined using time zone configuration under ['Refresh'](/power-bi/connect-data/incremental-refresh-overview#current-date-and-time).      |
 
 ### Response
 

powerbi-docs/connect-data/incremental-refresh-overview.md

@@ -150,11 +150,11 @@ For *very large* models in Premium capacities that likely contain billions of ro
 
 ### Current date and time
 
-By default, the current date and time is determined based on Coordinated Universal Time (UTC) at the time of refresh. For on-demand and scheduled refreshes, you can configure a different time zone under 'Refresh' that will be taken into account when determining the current date and time. For example, a refresh that occurs at 8:00 PM Pacific Time (US and Canada) with a time zone configured determines the current date and time based on Pacific Time, not UTC, which would return the next day. 
+By default, the current date and time is determined based on Coordinated Universal Time (UTC) at the time of refresh. For on-demand, scheduled and REST API refreshes, you can configure a different time zone under 'Refresh' that will be taken into account when determining the current date and time. For example, a refresh that occurs at 8:00 PM Pacific Time (US and Canada) with a time zone configured determines the current date and time based on Pacific Time, not UTC, which would return the next day. 
 
 :::image type="content" source="media/incremental-refresh-overview/time-zone.png" alt-text="Screenshot of Scheduled refresh dialog showing the Time zone input field":::
 
-Refresh operations not invoked through the Power BI service, such as the [XMLA TMSL refresh command](/analysis-services/tmsl/refresh-command-tmsl?view=power-bi-premium-current&preserve-view=true) or [enhanced refresh API](/power-bi/connect-data/asynchronous-refresh#parameters), do not consider the configured scheduled refresh time zone and default to UTC.
+Refresh operations not invoked through the Power BI service, such as the [XMLA TMSL refresh command](/analysis-services/tmsl/refresh-command-tmsl?view=power-bi-premium-current&preserve-view=true), do not consider the time zone configuration and default to UTC.
 
 ## Configure incremental refresh and real-time data
 
@@ -214,7 +214,7 @@ For example, if this setting is enabled, with each refresh operation, the servic
 
 The **Only refresh complete days** setting ensures all rows for the entire day are included in the refresh operation. This setting is optional *unless* you enable the **Get the latest data in real time with DirectQuery (Premium only)** setting. For example, say your refresh is scheduled to run at 4:00 AM every morning. If new rows of data appear in the data source table during those four hours between midnight and 4:00 AM, you don't want to account for them. Some business metrics, like barrels per day in the oil and gas industry, make no sense with partial days. Another example is refreshing data from a financial system where data for the previous month is approved on the twelfth calendar day of the month. You could set the refresh period to one month and schedule the refresh to run on the twelfth day of the month. With this option selected, it would, for example, refresh January data on February 12.
 
-Keep in mind, unless scheduled refresh is configured for a non-UTC time zone, refresh operations in the service run under UTC time, which can determine the effective date and complete periods.
+Keep in mind, unless time zone under 'Refresh' is configured for a non-UTC one, refresh operations in the service run under UTC time, which can determine the effective date and complete periods.
 
 The **Detect data changes** setting enables even more selective refresh. You can select a date/time column used to identify and refresh only those days where the data has changed. This setting assumes such a column exists in the data source, which is typically for auditing purposes. This column *shouldn't* be the same column used to partition the data with the `RangeStart` and `RangeEnd` parameters. The maximum value of this column is evaluated for each of the periods in the incremental range. If it hasn't changed since the last refresh, there's no need to refresh the period, which could potentially further reduce the days incrementally refreshed from three to one.
 

powerbi-docs/consumer/org-app-items/org-app-items.md

@@ -8,19 +8,13 @@ ms.service: powerbi
 ms.subservice: pbi-explore
 ms.search.form: Get started with org apps
 ms.topic: how-to
-ms.date: 09/24/2024
+ms.date: 10/14/2024
 ms.custom:
 LocalizationGroup: Share your work
 ---
 # Get started with org apps (preview) 
 
-> [!IMPORTANT]
-> **Opting in to the preview of org apps as items has been temporarily removed and will return soon.**
-> To ensure quality in functionality and experience, the preview switch for org apps has been temporarily removed for customers who have not already opted in. Customers in preview can still create new org app items, and existing org app items can still be edited and viewed. However, there is an issue with report pages pane not appearing when viewing org apps. The preview will be available again soon for all customers once the issue is fixed.
-
-**Coming soon:** the preview for org apps as items, Power BI workspace apps rebuilt for Fabric as a new item type. With org apps as items, you can create multiple org apps per workspace. And you can manage org apps the way you would any other item type - from creating a new org app, to managing access, or sharing an org app - what you find familiar and easy about managing other items, like a report, are all familiar with org apps as items.
-
-Welcome to the preview for org apps as items, Power BI workspace apps rebuilt for Fabric as a new item type. With org apps as items, you can create multiple org apps per workspace. You can also manage org apps the way you would any other item type - from creating a new org app, to managing access, or sharing an org app - what you find familiar and easy about managing other items, like a report, are all familiar with org apps as items.
+Welcome to the preview for org apps as items - Power BI workspace apps rebuilt for Fabric as a new item type. With org apps as items, you can create multiple org apps per workspace. And you can manage org apps the way you would any other item type - from creating a new org app, to managing access, to sharing the org app - all the things you find familiar and easy about managing other items, such as reports, are all familiar with org apps as items as well.
 
 ![Collage image of managing an org app item.](media/org-app-items/org-app-item-management-collage.png)
 
@@ -80,7 +74,7 @@ When you give users access to the org app item, **at a minimum they gain read ac
   - With workspace apps, only specific roles within the workspace could manage access and share the app.
 - Users who have access to an org app don't have to install the org app to view it. The org app item appears in lists like other items do, **Recent on Home**.
   - With workspace apps, a user had to install an app to see it in lists.
-- If a user is removed from an org app, that user loses their org app-based access to included items and semantic models associated with that org app. If a user has another form of access to included items or semantic models that form of access is unaffected.
+- If a user is removed from an org app, that user’s org-app-based access to included report items and semantic model items associated with that org app is automatically revoked. If a user has another form of access to included items or semantic models, that form of access is unaffected. (Automatic revocation of included real-time dashboard and notebook items is coming soon.)
   - With workspace apps, if a user was removed from an app their access to semantic models remained. Revoking access to semantic models had to be done manually. App authors had to be sure that they weren't breaking that user's ability to view other reports when removing model access.
 
 ### Workspace apps continue to work alongside org app items (preview)
@@ -281,16 +275,23 @@ Want to grant extra permissions to a user? Find the user you would like to manag
 
 - **Add reshare** allows users to share the org app item, included items, and underlying items with others. This means they can grant others access to the org app and propagate access to all items the org app is dependent on. Items like included reports, notebooks, and real-time dashboards. Plus the underlying semantic models the report items depend on.
 - **Remove reshare** removes a user's ability to share the org app item with others. Though anyone who has access to the org app by that user maintains access. 
-- **Remove access** removes that user's access to the org app item, the included items, and the semantic models that reports in the org app source from. Unique to new org app items, access to all lineage items is removed when a user loses access to an org app. Though if a user has another form of access to an item, like a semantic model, they maintain access to that item. Only their org app-based access is removed. 
+- **Remove access** removes that user's access to the org app item, the included report items, and the semantic model items that reports in the org app source from. Unique to new org app items, access to lineaged report and semantic model items is removed when a user loses access to an org app. However, if a user has another form of access to an item, such as a semantic model, they maintain access to that item. Only their org app-based access is removed. (Automatic revocation of included real-time dashboard and notebook items is coming soon.)
 
 > [!NOTE]
-> There are select cases where your org app doesn't automatically propagate access to items the org app is dependent on. For example, a report with a paginated report visual, also known as a report definition language (RDL) visual, is dependent on a paginated report item. Org apps don't propagate access to underlying paginated reports at this time. If your org app consumers have a broken view in an org app, consider all the items your consumers need access to, grant necessary access, and have your consumers view the org app again. 
+> There are select cases where your org app doesn't automatically propagate or revoke access to items the org app is dependent on.
+> **Access propagation**: For example, a report with a paginated report visual, also known as a report definition language (RDL) visual, is dependent on a paginated report item. Org apps don't propagate access to underlying paginated reports at this time. If your org app consumers have a broken view in an org app, consider all the items your consumers need access to, grant necessary access, and have your consumers view the org app again.
+> **Access revocation**: Org apps propagate access to Fabric items, such as real-time dashboard and notebook items included in the app, but do not yet revoke access automatically when a user loses access to an org app or those items are removed from the org app. Manage access removal of these items from each item's permissions management page.
 
-Here are the items org apps propagate and revoke access to: 
+Here are the items org apps propagate access to: 
+- The org app item itself 
+  - Included report items 
+    - The underlying semantic model for a report item (for a model in the same workspace or separate workspace)
+  - Included notebook or real-time dashboard items
+
+Here are the items org apps revoke access to: 
 - The org app item itself 
   - Included report items 
     - The underlying semantic model for a report item (for a model in the same workspace or separate workspace)
-  - Included notebook or real-time dashboard items 
 
 ### Insufficient permissions when managing an org app
 

powerbi-docs/developer/visuals/about-dialog.md

@@ -12,7 +12,7 @@ ms.date: 07/15/2024
 #customer intent: As a Power BI user, I want to know what permissions a visual requests so that I can make an informed decision about using it.
 ---
 
-# About Power BI visuals
+# The Power BI visuals *About* dialog
 
 Every visual has an *About* dialog that gives you information about the visual, including the version number, who created it, and what permission it requests. 
 
@@ -68,7 +68,7 @@ The visual might want to [store data locally](./local-storage.md) on the user's
 
 This privilege allows a visual to send HTTP requests to specific URLs that the visual builder declares in advance.
 
-There is no tenant admin switch for this permission. As long as [non-certified visuals are allowed](/fabric/admin/organizational-visuals#certified-power-bi-visuals), this privilege is granted.
+There's no tenant admin switch for this permission. As long as [noncertified visuals are allowed](/fabric/admin/organizational-visuals#certified-power-bi-visuals), this privilege is granted.
 
 ### Call Power BI Download APIs
 

powerbi-docs/developer/visuals/visuals-how-to-debug.md

@@ -1,6 +1,6 @@
 ---
-title: How to debug Power BI custom visuals
-description: This article describes procedures the developer can use to debug Power BI custom visuals and provides helpful tips for troubleshooting.
+title: Debug Power BI custom visuals
+description: This article describes procedures that developers can use to debug Power BI custom visuals, and it provides helpful tips for troubleshooting.
 author: mberdugo
 ms.author: monaberdugo
 ms.reviewer: tebercov 
@@ -12,16 +12,14 @@ ms.date: 07/31/2023
 
 # Debug Power BI custom visuals
 
-This article describes some basic debugging procedures you can use when developing your visual. After reading this article, you should be able use the following methods to debug your visual:
-
-* [Insert breakpoints](#insert-breakpoints)
-* [Catch exceptions](#catch-exceptions)
-* [Log exceptions](#log-exceptions-with-a-decorator)
+This article describes some basic debugging procedures that you can use when developing your visual. After you read this article, you should be able to debug your visual by inserting breakpoints and working with exceptions.
 
 ## Insert breakpoints
 
-The visual's entire JavaScript is reloaded every time the visual is updated Therefore, any breakpoints you add will be lost when the debug visual is refreshed. As a workaround, use `debugger` statements in your code. It's recommended to turn off auto reload while using `debugger` in your code.
-Here's an example of how to use a `debugger` statement in your *update* method.
+The visual's entire JavaScript is reloaded every time the visual is updated. Any breakpoints that you add will be lost when the debug visual is refreshed.
+
+As a workaround, use `debugger` statements in your code. We recommend that you turn off automatic reload while using `debugger` in your code.
+Here's an example of how to use a `debugger` statement in your `update` method:
 
 ```typescript
 public update(options: VisualUpdateOptions) {
@@ -33,13 +31,13 @@ public update(options: VisualUpdateOptions) {
 
 ## Catch exceptions
 
-When working on your visual, you'll notice that all errors are 'consumed' by the Power BI service. This is an intentional feature of Power BI. It prevents misbehaving visuals from causing the entire app to become unstable.
+When you're working on your visual, you notice that the Power BI service "consumes" all errors. This behavior is an intentional feature of Power BI. It prevents misbehaving visuals from causing the entire app to become unstable.
 
 As a workaround, add code to catch and log your exceptions, or set your debugger to break on caught exceptions.
 
-## Log exceptions with a decorator
+### Log exceptions with a decorator
 
-To log exceptions in your Power BI visual, you need define an exception logging decorator. To do this, add the following code to your visual:
+To log exceptions in your Power BI visual, you need define an exception-logging decorator. To define the decorator, add the following code to your visual:
 
 ```typescript
 export function logExceptions(): MethodDecorator {
@@ -58,40 +56,38 @@ export function logExceptions(): MethodDecorator {
 }
 ```
 
-You can use this decorator on any function to see error logging as follows.
+You can use this decorator on any function to see error logging as follows:
 
 ```typescript
 @logExceptions()
 public update(options: VisualUpdateOptions) {
 ```
 
-## Break on exceptions
+### Break on exceptions
 
-You can also set the browser to break on caught exceptions. Breaking stops code execution wherever an error happens, and allows you to debug from there.
+You can set the browser to break on caught exceptions. Breaking stops code execution wherever an error happens, and you can debug from there.
 
-### [Microsoft Edge](#tab/Edge)
+#### [Microsoft Edge](#tab/Edge)
 
-1. Open **developer tools** (F12).
+1. Open DevTools (F12).
 2. Go to the **Sources** tab.
-3. Select the **Pause on exceptions** icon (stop sign with a *pause* symbol).
-4. Select **Pause on caught exceptions**.
+3. Select the **Pause on exceptions** icon (stop sign with a pause symbol).
+4. Select the **Pause on caught exceptions** checkbox.
 
-    ![Screenshot shows the Debugger tab with Break on all exceptions selected.](media/visuals-how-to-debug/how-to-debug-edge-2.png)
+    ![Screenshot of DevTools in Edge that shows the Sources tab with the pause option selected.](media/visuals-how-to-debug/how-to-debug-edge-2.png)
 
-### [Chrome](#tab/Chrome)
+#### [Google Chrome](#tab/Chrome)
 
-1. Open **developer tools** (F12).
-2. Go to the  **Sources** tab.
+1. Open DevTools (F12).
+2. Go to the **Sources** tab.
 3. Select the **Pause on exceptions** icon (stop sign with a pause symbol).
-4. Select the **Pause On Caught Exceptions** check box.
+4. Select the **Pause On Caught Exceptions** checkbox.
 
-    ![Screenshot shows Sources tab with Pause On Caught Exceptions selected.](media/visuals-how-to-debug/how-to-debug-chrome.png)
+    ![Screenshot of DevTools in Chrome that shows the Sources tab with the pause option selected.](media/visuals-how-to-debug/how-to-debug-chrome.png)
 
 ---
 
 ## Related content
 
-* [Troubleshoot Power BI visuals](power-bi-custom-visuals-troubleshoot.md)
+* [Troubleshoot your Power BI developer environment setup](power-bi-custom-visuals-troubleshoot.md)
 * [Frequently asked questions about Power BI visuals](power-bi-custom-visuals-faq.yml)
-
-More questions? [Try the Power BI Community](https://community.powerbi.com/)