Hi An,

Versions and Revisions are not the same thing. The Changes field (version-level) on a version would describe the reason for this version (or first version) to exist. It could indeed be the initial creation and the reason is then probably in the title (logical-level). Within that version your contributors will probably push multiple revisions of that message and will push that version through your workflow.

There are several levels on which you can make things mandatory.

1. First level is in the database, by deliberately making a field mandatory, this means that all business code will respect that. It also means that all data in the database has to have values.
2. The plugin system, can enforce a check on mandatory. This way all clients, including custom clients over the Api, will be forced to align. Of course through plugin configuration tweaking you could decide variations where desired.
3. The user interface, typically configured by metadataconfig.xml, can force fields to contain values before they are even submitted to the Api and in turn database.

I assume you tweaked metadataconfig.xml which caused your customers to push back.

By default the Changes field is configured as

<ishfrmfield id="ChangesField" name="ChangesField" ishfieldref="FCHANGES" level="version">
    <label resourceref="FCHANGES.Label">&Changes</label>
    <description resourceref="FCHANGES.Description">Reason for a new version.</description>
    <typemultilinetext lines="2" />
    <value overwrite="yes" ishcondition="ChangeMode in ('NewVersion', 'Create') and not (CreateReason = 'NewLanguage')" />
</ishfrmfield>

It is here that you can look into variations of the ishconditions on the mandatory tag (assuming you did it this way). So only make the field mandatory on certain ChangeModes or CreateReasons, inspiration is on https://docs.rws.com/955882/940957/tridion-docs-14-sp4/understanding-the-use-of-conditions-in-metadata-configuration If possible I would try to find a way to not initialize with "Initial version" as that adds no value IMHO and just makes the database grow faster.

Best wishes,
Dave

Hi An,

Versions and Revisions are not the same thing. The Changes field (version-level) on a version would describe the reason for this version (or first version) to exist. It could indeed be the initial creation and the reason is then probably in the title (logical-level). Within that version your contributors will probably push multiple revisions of that message and will push that version through your workflow.

There are several levels on which you can make things mandatory.

1. First level is in the database, by deliberately making a field mandatory, this means that all business code will respect that. It also means that all data in the database has to have values.
2. The plugin system, can enforce a check on mandatory. This way all clients, including custom clients over the Api, will be forced to align. Of course through plugin configuration tweaking you could decide variations where desired.
3. The user interface, typically configured by metadataconfig.xml, can force fields to contain values before they are even submitted to the Api and in turn database.

I assume you tweaked metadataconfig.xml which caused your customers to push back.

By default the Changes field is configured as

<ishfrmfield id="ChangesField" name="ChangesField" ishfieldref="FCHANGES" level="version">
    <label resourceref="FCHANGES.Label">&Changes</label>
    <description resourceref="FCHANGES.Description">Reason for a new version.</description>
    <typemultilinetext lines="2" />
    <value overwrite="yes" ishcondition="ChangeMode in ('NewVersion', 'Create') and not (CreateReason = 'NewLanguage')" />
</ishfrmfield>

It is here that you can look into variations of the ishconditions on the mandatory tag (assuming you did it this way). So only make the field mandatory on certain ChangeModes or CreateReasons, inspiration is on https://docs.rws.com/955882/940957/tridion-docs-14-sp4/understanding-the-use-of-conditions-in-metadata-configuration If possible I would try to find a way to not initialize with "Initial version" as that adds no value IMHO and just makes the database grow faster.

Best wishes,
Dave

Thanks for the quick reply Dave. Yes, I made the change in metadataconfig.xml as follows

<ishfrmfield id="ChangesField" ishfieldref="FCHANGES" level="version" name="ChangesField">
        <label resourceref="FCHANGES.Label">&Changes</label>
        <description resourceref="FCHANGES.Description">Reason for a new version.</description>
        <typemultilinetext lines="2"/>
		<mandatory/>
        <value ishcondition="ChangeMode ='NewVersion'" overwrite="yes"/>
</ishfrmfield>

Hi,

Is there any combination of these ishconditions that differs when creating an initial version of an object versus subsequent versions of it?

From testing with topics, the ChangeMode seems to always be Create and the CreateReason seems to always be NewObject.

Thanks,

Ann