No supported way to set the author of a tracked change on 2.x (1.x had editor.setOptions({ user }))

[nandoofz]

Environment: superdoc@2.12.0 + @superdoc/react@2.7.0 (@superdoc/docx-engine@0.11.0), browser adapter, Chrome 152. Compared against superdoc@1.45.0.

What changed

On 1.x a host could attribute a programmatic tracked change to a chosen author by swapping the editor's user around the write:

editor.setOptions({ user: { name: 'Automated Reviewer', email: 'bot@example.com' } })
await doc.replace({ target, text }, { changeMode: 'tracked' })
editor.setOptions({ user: originalUser })

The created w:ins / w:del carried w:author="Automated Reviewer".

On 2.x setOptions and options.user are gone, and we could not find a replacement. What we looked at:

• superdoc.user is the closest surviving field. Mutating it around the write does not reach the mark: the revision comes out attributed to the signed-in user, the one passed as user at construction.
• MutationOptions accepts changeMode, dryRun and expectedRevision only.
• TextReplaceInput accepts target / ref, text and in.
• No setUser or equivalent method on the public surface.
• modules.trackChanges exposes enabled, visible, mode, replacements, authorColors and semanticColors. authorColors colours an author but does not set one.

If there is a supported way to do this that we missed, pointing at it would be enough and this can be closed.

Why it matters

An application that writes tracked changes on the user's behalf cannot distinguish them from the user's own. Both come out under the same name, so opening the file in Word shows one author for two different kinds of edit, and nothing downstream (accept/reject by author, filtering, audit) can separate them.

Steps to reproduce

1. Construct SuperDoc with user: { name: 'Human Editor', email: 'human@example.com' }.
2. Set superdoc.user = { name: 'Automated Reviewer', email: 'bot@example.com' }.
3. await doc.replace({ target, text }, { changeMode: 'tracked' }) over any text range.
4. Read the created revisions back with doc.trackChanges.list(...), or export and inspect w:author on the new w:ins / w:del.
5. Observed: Human Editor. Expected: Automated Reviewer, as 1.x produced with setOptions.

Restoring superdoc.user after the write, or leaving it swapped, makes no difference.

Ask

A supported way to set the author of a tracked change created through the Document API. Either of these would work for us:

1. An author field on MutationOptions, so it is per write and needs no global mutation.
2. A documented instance-level setter, the 2.x equivalent of setOptions({ user }).

[caio-pizzol]

@nandoofz We reproduced this on current main: tracked replacements retain the user supplied when the editor opens, even after changing superdoc.user. Starting with the bot identity attributes changes correctly, but we haven’t found a supported way to switch authors within the same session.

We’ve added the reproduction and findings to our existing tracking issue - the team is investigating and will come back as soon as we have updates.

[nandoofz]

Hi @caio-pizzol, following up on our call, and thanks for reproducing it so quickly.

This is the lowest priority of the five for us. Since attribution works when the session is constructed with the automation identity, we have a way forward using a separate session. It would only become pressing if we write on the user's behalf from inside their own live session.