Update/PatchCommand insight

Development
1

Hey there Sebastian! I created a plugin that extends the scripting library to allow updates to the content references when the parent is updated. I have the whole JInt callback wired up and am working through updating the content from the EmbeddedContent item that is passed through getReferences. Is there any insight or thing you’d point me to in understanding the content update flow a little better? When I’m calling PublishAsync on the ICommandBus, it’s throwing an exception at DomainObject.EnsureCommand (failing at CanAccept).

I started looking at how you are calling EnsureLoaded in other update methods, but wanted to make sure I was going down the right path. It’s also happening within the context of a content item being updated, so I also wasn’t sure if loading DomainObject with a separate content type would break things as well. Any help you may be able to point me towards would be greatly appreciated.

Also, I created a JInt wrapper for your ISemanticLog so that you can call log.information or log.warning and it will go to the output writer with the objects serialized properly. Is that something you think would benefit the community?

Appreciate all the hard work you’ve done on this… super impressive.

private void UpdateContent(ScriptExecutionContext context, ClaimsPrincipal user, JsValue value,
        Action<JsValue> callback)
    {
        if (callback == null) throw new JavaScriptException("Callback is not defined.");

        var obj = value.IsObject() ? value.AsObject() : null;
        if (obj == null) throw new JavaScriptException("updateContent parameter must be an object");

        var wrapped = obj.AsWrapped();
        if (wrapped is EnrichedContent ec)
        {
            context.Schedule(async (scheduler, ct) =>
            {
                var actor = user.Token();

                if (actor == null)
                {
                    scheduler.Run(callback, new JsString("No user defined"));
                    return;
                }

                var command = new PatchContent()
                {
                    Actor = actor,
                    AppId = ec.AppId,
                    ContentId = ec.Id,
                    Data = ec.Data,
                };

                var commandBus = serviceProvider.GetRequiredService<ICommandBus>();
                var commandContext = await commandBus.PublishAsync(command, ct);
                scheduler.Run(callback, JsValue.FromObject(context.Engine, new JsString("Success")));
            });
        }
    }
2

I think you are just schema id in your command. The accept method ensures some consistency, so that you do not mix app ID, schema ID and content ID, see: https://github.com/Squidex/squidex/blob/master/backend/src/Squidex.Domain.Apps.Entities/Contents/DomainObject/ContentDomainObject.cs#L48

Yes and no. The question is: Who wants to see it. Only an administrator would see that, which often is not the same as a the person who creates rules and scripts. I also do not want to have it for the cloud. So if we add it, we need a option for that to turn it off or on.

Ideally we also have a custom log stream (in mongodb), that is accessible by the app user via API and UI, but this would be much more work.

Thank you :slight_smile: