Extend existing content type / aspect with bootstrap approach?

[drewsmethew]

Dear community,

I'm looking for a solution to accomplish the following:

An existing content type should be enhanced with a new property for an aspect and the new property should be visible in Share for all documents of the content type (even for the existing documents).

Background:

There is an Alfresco extension available that is shipped as a third-party AMP file. This AMP contains the affected content type that should be extended. We now create an add-on for this AMP file which should be available as another AMP file (assuming our new AMP has the dependency information in its module.properties: module.depends.com.mw.support.NetViewer=1.0-*).

I want to know the necessary steps to add a new property to an existing aspect (of the original AMP) and make the new property visible in Alfresco Share even for existing documents. Is that possible at all? If not, another option on our side would be to extend the existing content type with a new mandatory aspect that contains our property.

Is there any advice for my issue? Or best-practice? Or tutorials? 

I appreciate any help!

Methew

[afaust]

For some reason I remember a similar question from earlier today, but can no longer find it (even in my own Activities). Did you create a similar question previously and by any chance delete it?

Anyway - there is no support to directly enhance an existing 3rd-party model by adding properties to it. The dictionary system in Alfresco does not allow modification of a model after it has been bootstrapped. The Alfresco content model modelling tool works around this by removing and re-bootstrapping the model after a change.

Typically you will have to create a custom type that inherit from a type of that 3rd-party model to add your own properties. Depending on how the 3rd-party AMP module is built, you may need to configure some UI components for your custom type(s) to be used. In some instances the AMP may not support any kind of configuration. If push comes to shove you can usually always fall back to adding a custom behaviour that automatically specializes a node to a sub-type, e.g. when the 3rd-party AMP module functionality creates an instance of their type your policy could then immediately specialize the node to your type that extends the original one.

For existing documents you would have to write some kind of patch component / script that looks up all the existing nodes of the 3rd-party model type and retro-actively specializes them to your custom extension type.