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:
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.
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:
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}.