Can I set default value for mandatory Changes field on creation of initial versions of content items?

Hi,

I am getting pushback from my customers now that the Changes field on the Versions tab of the Properties box is mandatory for all content items. Is there any way to set a default value for the initial version of a new content item so that it can be pre-populated with something like Initial version?

Any advice appreciated,

Regards,

Ann

  • 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>

    However, I don't fully understand the impact of these ishconditions on the mandatory tag; what does it mean if I use the ChangeMode value of Create versus NewVersion and what is the impact of using the ishcondition CreateReason versus leaving it out?

    Can you advise if there is documentation other than https://docs.rws.com/955882/940957/which%2520conditions%2520are%2520currently%2520used%253F that explains these as I am still unclear?

    Thanks again,

    Regards,

    Ann

  • 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