Another argument: once author starts editing UMO he may not know for sure
if his changes are minor or versioned. He may make his decision only after
he is finished with his changes.
> This is not what we have in specs and mailing list discussions, maybe
> something changed recently and I missed it, though. Also it's very user
> unfriendly imho.
> Author makes minor changes to the UMO until he satisfied with it's
> content, then publishes it. From UI point of view, when creating new
> version of UMO, user expirience should be exactly the same as with minor
> changes, except selecting "versioned" radio button on submit(or clicking
> "Publish" instead of Save")
> Also new version supposed to be created when user changes UMO
> content(adds/removes children UMOs) and this should be reflected in
> topic_create_version() too.
>> The idea was - you 1) create version 2) update any information in the
>> The reason for it is pretty simple. Title and description belong to
>> record. Since we may have multiple content records (one per language),
>> providing a single content record information doesn't make much sense.
>> is universal approach for all the UMOs in the database.
>> 2007/5/5, firstname.lastname@example.org < email@example.com>:
>>> I'm working implementing versions functionality for topic and have
>>> with it.
>>> Currently topic_create_version() gets only topic ID as a parameter.
>>> author creates new version, he may change title, description and
>>> content(child UMOs that belong to this topic). The way this stored
>>> procedure work now, it only duplicates all topic properties without
>>> updating them.
>> Alexey Parshin,
Authoright © Total Knowledge: 2001-2008