Contrib.social

Make expand parameters in getAsset configurable so users can select what information is requested

Open on Drupal.org →
Created on 10 October 2023, over 1 year ago

Problem/Motivation

There's a @todo comment in /src/Client/AcquiaDamClient.php to consider making the expand parameters in the getAsset method configurable. This is a great idea! Can we do that?

try {
      // @todo make this configurable, maybe?
      $expand = 'asset_properties,embeds,file_properties,metadata,metadata_info,metadata_vocabulary,security,thumbnails';

Proposed resolution

Add configuration to /admin/config/acquia-dam to allow users to select parameters. I'm not sure if I have the right wording, but something like:

Select assets to include in response.
Checkboxes with options: asset_properties,embeds,file_properties,metadata,metadata_info,metadata_vocabulary,security,thumbnails.

Remaining tasks

Question: Should the list of options be hardcoded to the current options? Or could/should they be dynamically generated?

User interface changes

Update Acquia Dam admin config page with checkboxes to select which parameters should be included in the getAsset response.

✨ Feature request
Status

Active

Version

1.0

Component

User interface

Created by

🇺🇸United States capysara

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @capysara
  • Comment over 1 year ago →
    🇺🇸United States japerry KVUO

    Bump for jira

  • Comment 6 months ago →
    🇭🇺Hungary Balu Ertl Budapest 🇪🇺

    The case is that there are no or only very few benefits to making it configurable. This GET parameter (docs) controls how much detailed data the API should include in its response regarding the given asset. As the module utilizes its own HTTP Client responsible for sending most of the external requests, and each API endpoint has a dedicated method to call. Nowhere else within the entire codebase of the module does this expand GET parameter have an effect. Therefore, I tend to suggest rather simply deleting these @todo comments and leaving this expand parameter the most optimized for each endpoint as possible.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024