Skip to main content

Filter by idea status

10000+ Ideas

DavidParke
DavidParkeKnown Participant

Make the blue export/import alerts in Premiere clickable so they navigate directly to the asset the alert is about, instead of only opening the Events panel.Open for Voting

In Premiere 26.3.0 (build 93), blue alerts currently slide in at the bottom-right of the UI to confirm actions like exports and imports. For example:Exporting a still frame shows a blue alert with the full path to the exported file, such as: “Exported frame /Volumes/WK_SSD_4TB_A/GFX/STILLS/…Still003.jpg.” Using the Watchtower panel to import files from a monitored Finder folder into a specific bin shows a blue alert like: “[PROJECT].prproj: 1 file imported in 03C_PHOTOS, STILLS.”  However, clicking these alerts only opens the Events panel. The Events panel shows a log of recent events, but in the moment when the alert appears, what I actually need is quick navigation to the asset or bin referenced in the notification. The alert already contains the exact filename, path, project, and bin information—yet none of that is actionable with a click. This creates friction in everyday workflows:When I export a still, the very next step is usually to reveal that image in Finder/Explorer or bring it into another app. Right now I have to manually navigate through Finder to find it. When Watchtower imports new files into a bin, the a nice optional next step would be to go straight to that bin in the Project panel and start working with those assets. Instead, I have to scroll/search in the Project panel to locate the bin and then the newly imported clip or still.Requested behavior:Export alerts Clicking a blue export alert should reveal the exported file in Finder/Explorer (or at least provide a clear “Reveal in Finder/Explorer” action). This would mirror Adobe Media Encoder, where clicking an export path reveals the rendered file. Users already expect that behavior across Adobe video tools. Import alerts (including third‑party panels like Watchtower) Clicking an import alert should open the bin mentioned in the alert within the Project panel and select the newly imported asset. If the alert references only the bin, selecting the bin is still better than opening the Events panel, because it gets the editor directly to the relevant part of the project. Why this matters:It turns passive notifications into active navigation shortcuts. It reduces repetitive panel and Finder hunting, which is especially painful in large projects with deep bin structures. It improves integration with third‑party panels like Watchtower that already use the alerts to communicate exactly where assets were imported. It makes Premiere’s behavior more consistent with Media Encoder and other Adobe tools, where clicking something that references a file helps you get to that file.From a UX perspective, even a preference option such as: “On notification click: Open Events panel / Reveal asset / Ask each time” would allow different kinds of editors to choose the behavior that fits their workflow, while still making the alerts more useful than they are today. 

christopher5E41Participant

enable administrator to configure All Apps profiles to exclude certain appsOpen for Voting

Adobe has discontinued a number of products over the years:  Animate, Dimension, and some others.In our organization, we would like to restrict our user from using these applications, as they create potential support issues and security concerns. For Single App users, we’ve removed the application profiles for these discontinued apps.  But the apps remain available for install by our users with the All Apps license.  We deploy Creative Cloud as a Self Service package, so our All Apps users have the ability to install every application, even those that have been discontinued.  As an administrator, I would like to have greater control over this, at the product profile level, to select/deselect the list of applications that are available to those All Apps users who have been assigned a given product profile.  I can foresee this being useful in a multitude of ways.  Not only could we disable specific applications which we do not wish to support, such as the discontinued products as I mentioned above.  But we could create bundles that are specific to a particular role or profession, so we can bundle and deploy an All Apps license that has just those applications useful for, for example, Video Production, or Print Publishing, or Graphic Design, for example, and this would enable us to deploy the specific apps that a user in such role needs, and realize a cost savings vs. assigning multiple Single App licenses to the user’s account, while still controlling the user’s access to the suite such that they only have the ability to install and use those apps that are specific to their role or job title.

javier_1058Participant

Improve API documentation by listing required permissions for each endpointOpen for Voting

As global platform administrators, we are responsible for creating Developer Console credentials and distributing them to each sandbox administrator. These credentials are intentionally configured with the minimum permissions required to perform the requested action.Today, when a sandbox administrator requests access to a capability such as Data Ingestion, we can find the API documentation that explains the available endpoints and how to use them. However, we cannot find clear information in either the API documentation or Experience League about which specific permissions are required for each operation.For example, the documentation may describe a method such as POST – Create a new batch, including the request format and usage, but it does not indicate which AEP permissions must be assigned to the Developer Console credential in order to execute that operation successfully.Requested improvement:Please add, within each API method or endpoint documentation page, a small highlighted section that clearly states the required permissions/roles/scopes needed to use that operation.Example:For POST – Create a new batch, include a note or box indicating the exact AEP permissions that must be granted to the credential in Developer Console.Why this is important:Helps administrators assign the correct minimum permissions from the start Reduces trial and error when configuring credentials Speeds up onboarding for sandbox administrator and teams consuming the APIs Improves security by reinforcing least-privilege access Reduces support requests caused by missing or unclear permission requirements 

P: SDK: Restore ability of Copy Settings plugin to work around longstanding LR bugsOpen for Voting

LR 15.4 changed the representation of brush masks returned by photo:getDevelopSettings(), making it impossible for the Copy Settings plugin to provide a workaround for the numerous, longstanding bugs copying local adjustments between photos with different orientations.  A relatively simple change to the implementations of SDK methods photo:getDevelopSettings() and photo:applyDevelopSettings() would restore the ability of Copy Settings to copy local adjustments correctly, lessening the need for Adobe to fix all the bugs in Copy/Sync Settings. Details Prior to LR 15.4, the strokes of a brush mask were represented by a "Dabs" array of points: Dabs = {    [1] = "d 0.038236 0.022757",     [2] = "d 0.037902 0.025261",     [3] = "d 0.037802 0.027775",     [4] = "d 0.037799 0.030289",     [5] = "d 0.037798 0.032803",  When copying a brush mask, the Copy Settings plugin would translate these points to match the orientation of the target photo, so that the mask would appear in the correct position. But as part of significantly improving the performance of brush masks, LR 15.4 changed the representation of strokes. When there are fewer than 250 points, it uses the original Dabs representation. But when there are more, it encodes them as an opaque BrushTable: BrushTable_31A27BD834AA19BF4C899DCF07AE14C1 = "4000010000}`800Xs0009am20U$F(tIU-d(SvmV(-cF+p]zwB]K-h@@arV7O@Lyjh1N1=qxwU[ocAW!(`m.{jnT52Ju9rgiQt9%`Ug3nOv2FNnwDs#MzBM0AAVyJM][D( This prevents the plugin from translating the points of the strokes to match the target photo's orientation. Proposal photo:getDevelopSettings() should always return the Dabs representation of brush masks, converting from the internal BrushTable representation to the Dabs format. photo:applyDevelopSettings() should accept the Dabs representation and convert it to the internal BrushRepresentation. This code already exists to handle the transition from the LR 15.3 representation to that of LR 15.4. This would have zero impact on built-in features, which would continue to use the current BrushTable representation. It would have very minimal performance impact on plugins invoking getDevelopSettings() and applyDevelopSettings().