Share-Links after migration available but not working

[apiening]

We have exported some sites out of our ACS 5.1 installation with the bulk export tool and imported them in a ACS 6.1 instance with the bulk import tool.

The share option, including the share-link-suffix has been exported and imported via the metadata.properties.xml and the documents that has been shared before in ACS 5.1 does show up in ACS 6.1 as shared.

However, the links does not work. Instead an error page states "Page not available. It seems that this shared file link has been removed" (translated, the actual error message from our system is german).

Does anyone know why this is and how to fix it?

Maybe there is an option to iterate over all shared nodes and activate the shared-link via a web script?

With kind regards

Andreas

[jljwoznica]

Did you move the content to a different location? it is possible that the content is not available at the location specified in the database.

[afaust]

The problem may very well be caused by additional data not migrated as part of the bulk export / import cycle. The QuickShareService manages some data in the alf_prop_* tables inside the database via the AttributeService. These attributes are global key value which are not exported using bulk export / import. The metadata alone (which was migrated) is not sufficient to make quick share work.

In the code I can see some workarounds stemming from Enterprise support tickets, e.g. https://issues.alfresco.com/jira/browse/MNT-16224, which fallback to node metadata if the attributes cannot be loaded from the AttributeService. This looks to be merged in in time for 6.0, so should be contained in your Alfresco version as well. Though the fallback has one potential conflict: if - through the use of export / import - multiple documents now exist with the same sharedId (from the share link), Alfresco is unable to resolve the link and will also throw an error.

I can see no (better) way to fix this other than going through the shared nodes and resetting / re-sharing them, resulting in new share links.

In addition to the share ID being maintained via AttributeService, there are various other elements of the quick share functionality that are stored separate from the node on which quick share is activated. E.g. the action to expire quick share links is stored via the (internal) ScheduledPersistedActionService in the data dictionary structure. So if the export / import did not include this dictionary, then more data will be missing.

[apiening]

Dear @jljwoznica,

we have exported the content based of a site root of instance A and then imported them into a site root of a different site on instance B.

My thinking was that the share links are based on the noderef, not on the actual path or site name.

[apiening]

Dear @afaust,

thank you very much for the deep insight on how the data related to the share links is stored / handled.

Since we're dealing with quite a few documents: Do you think it would be possible to select all nodes with an active quickshare link and iterate them with a web script and unshare and then reshare the nodes automatically?

With kind regards

Andreas

[afaust]

It should not be a problem to write a query and execute a script to remove the migrated quick share metadata from the affected nodes. This could be done easily in JavaScript Console (provided that addon is installed, which in my opinion it should absolutely be in any Alfresco system).

Re-sharing is a bit harder unfortunately, since there are no easy to use (JavaScript) APIs to use. But it should also be doable via JavaScript Console by using the Java interoperability features of the JavaScript engine and accessing the QuickShare Java service itself. Retrieving a Java service in JavaScript Console can be done like in this example (different use case). And the QuickShareService provides a simple shareContent method which should do the trick.