Problem/Motivation

Back at that time, when the current iteration of the bulk asset import of the 1.1.x branch was designed,
the focus was mainly on providing the best interoperability with the other contrib acquiadam_asset_import module. The way how that module stored its settings (category × asset type – source code) entirely misled our thinking into that direction to simply follow and copy over. In terms of Widen's advanced search logic, this means we already hardcoded 2 filtering options by this:

Screenshot

There are several shortcomings of this: for example, only top-level categories are supported (for some reason which I can't recall after a half year since writing that code). Plus, hearing the feedback from our beta testers playing around with the 1.1.0-rc1 release, Acquia customers have so varying use cases, for example, filter assets by their membership in groups.

Proposed resolution

As the hidden truth just became obvious to me recently (many months later since I wrote this bulk importer tool), the search endpoint of Widen API – which this module relies on to fetch asset data – supports even complex search queries pretty well. In other words, we can safely direct module users to Widen's GUI to put together any search query with the results they are satisfied with, then ask them to copy over the search term back to the Drupal module and paste it into our input field. Then our module will simply take the query as a string, pass it to Widen API, and IF there are any publicly available assets among the search results (otherwise the API does not hand out any asset that is not publicly available), then continue processing the received asset data, just it currently does. All these are just a theory, but an educated one. Just as usual, any unforeseen obstacles might arise.

Possible disadvantages

  1. Not all Drupal users are familiar with Widen GUI too:
    One minor UX inconvenience of this approach is the false assumption that “all Drupal users also have experience with using Widen”. For instance, consider a multinational holding company subscribed to Acquia DAM that operates a Widen instance at its headquarters, with write access restricted to their central design department. Now imagine one of its subsidiary companies in your country hiring interns for the summer to clean up and organize website content. Even if these interns are confidently moving around within Drupal, they still need to learn using a separate system to construct a search query string using Widen's GUI.

Remaining tasks

Collect more feedback, discuss the pro/contra arguments, arrive on an agreement, then write the code.

User interface changes

Here's a sketchy draft about how the form could be retailored:

Screenshot

API changes

Fortunately none. That's the good news in this entire story: our current API communication is already supposed to be capable to handle such queries.

Data model changes

Once this direction is accepted, don't forget to write DB update hooks to convert the current “category × asset type”-based settings of 1.1.0 users into the suggested new format which translates into cat:(CATEGORYNAME) at:{ASSETTYPE}.

Comments

baluertl created an issue. See original summary.

baluertl’s picture

Issue summary: View changes

Adding a possible disadvantage.

baluertl’s picture

Issue summary: View changes

It was probably a momentary lapse in judgment that led me to think, “Not all Drupal users are Widen users too”. Of course, they must have a registered user account; otherwise, they wouldn’t be able to authenticate themselves on the Drupal side either. As a result, I’ve downgraded the significance of this potential disadvantage to being a minor UX flaw instead.

baluertl’s picture

Also linking #3484967: Dynamic filter for collections here as well for visibility.

japerry’s picture

Status: Active » Closed (outdated)