+5
Rejected

Ability to manually manage publication items in INDD via UI

Maja Pejčić 12 months ago in Digital Asset Management updated by Gerda Oppewal 11 months ago 3

Working with INDDs in SaaS is still challenging, even though there are new tools available to manage them (package uploader, CC Connector). We still have clients that are not going to be able to rely on these tool for all their use cases that involve working with INDD. Therefore it would be useful to allow managing publication items on INDD assets manually - in other words have a UI option to link assets in Contains section as dependencies to the INDD (or course providing a way to link to select file version to link) or any alternative OOTB way. Consequently, the dependencies would automatically show where they are linked without additional manual intervention. 

Here is a use case: a client is not working with CC Connector because of performance issues (working with large assets with many links is still very slow), they are using package uploader to upload new assets via task or via My Uploads area. However, for certain INDDs where a dependency changes but the filename stays the same (CRC checksum for dependency is changed, but the dependency is essentially the same, just had some minor changes), this client doesn't want package uploader to add a new asset for that dependency, the intention is to add a version to existing asset instead and establish linking between dependency and INDD. There is no way to configure package uploader in this way since it detects duplicates based on checksum. So the only alternative would be for users to manage publication items themselves as they want - manually add a new version for dependency asset, add an new version for INDD and establish linking manually. 

In general, even historically speaking, managing links for INDDs has been a problem and we often had to resort to re-ingesting whole packages to fix broken links, when in fact it would've been useful to have an option to manage links manually and make small corrections. 

Since this can be a sensitive thing to change, it would be useful to have a functional permission for allowing management of publication items, to make a distinction between users who are able to modify assets and users who are considered power users/librarians that would potentially also be able to manage publication items. 

Content Types / Metadata Creative Cloud
Rejected

Thanks for the request and suggestions, we do understand the use case. However, we won't change the publication all item logic to solve this use case: The essence of this link is the direct relation of the placement of an asset into an InDesign file. That is a deeper relationship than e.g. a record link. You cannot manipulate that link manually while keeping this logic.

I try to clarify this with how we look at InDesign uses cases:

We want to keep a clear distinction between a 'Disconnected InDesign use case' and a 'Connected InDesign use case'. 

  1. The connected use case is intended to support a full work in progress process where links and versions are seamlessly managed through our CC Connector. 
  2. The disconnected use case will follow upload, download, linking and versioning logic of other DAM assets, which means that when you e.g. add a new InDesign file version it does not keep a link to the assets of the previous version since those assets were not actually placed into the last version. If you want to version the InDesign file it can only be properly done in terms of links through a work in progress connected use case (= checkout / in through the CC Connector). 

Having said that, we acknowledge that the CC Connector is not fully covering all use cases and production requirements yet, We have work planned to address those areas (performance, linking, package support, upload) starting this year but these are longer impactful tracks.

VOTE!  This is critical for us. 


And as more of your clients use the Packages functionality that was just released and have more and more INDD packages in the DAM, this will be critical for them as well.