Workspace Fields not updated after Smart Action if not on List

Help me!
,
1

Feature(s) impacted

Workspace fields + Smart Actions

Observed behavior

After a Smart Action in a Workspace is complete - The list (which is the source of that Smart Action) is updated with the requested fields = the ones show on the List.
Any field, of that collection which are placed in the Workspaces (outside of the list component) will not update at this points unless they are on the List component.

Note: If a smart field is requested on the List component - All fields are projected and so some Fields will update and appear to “normally refresh” but this is an artifact of the “remove projection” scenario of Smart Fields (returned for all flattened fields which are not smart fields)

Expected behavior

Workspace fields should update after Smart Actions are completed - or at least allow to specify those fields in the “refresh” response property of the Smart Action (only works for relationships today).

Env

  • Project name: WescoverContentAdmin
  • Environment name: Private Development
"meta": {
    "liana": "forest-express-mongoose",
    "liana_version": "8.7.6",
    "stack": {
      "database_type": "multiple",
      "engine": "nodejs",
      "engine_version": "16.18.0",
      "orm_version": "5.9.29"
    }
  }
2

I have tried the same setup with forest-express-mongoose : “9.3.11” and it seems to be working on my side.

I tested running the smart action in a collection, and the update is reflected to 2 other component:

  • a label containing the value
  • the same collection in a different component

Could you please upgrade to the latest forest-express-mongoose version and test again.
If you still see the issue, can you please provide some more info about your workspace, settings, and if you see any frontend or agent errors.

Thanks,

Regards
@Nicolas.M

3

Hi @Nicolas.M To make sure this is a Workspace thing and not related to the Liana version - I implemented a minimal repro on top of the new “agent” library (I hope this is good enough in this case, I cannot see why 9 vs 8 will fix this, but new agent vs 8 won’t).
From what I researched this is a design flaw in the Workspace feature and unrelated to server side API implementation - but I could be wrong of course.

Setup

The model

const Mongoose = require("mongoose");

const schema = new Mongoose.Schema({
  name: String,
  size: Number,
});

module.exports = {
  collectionName: "teams",
  modelName: "Team",
  schema,
};

Setup of the agent:

agent.addDataSource(
  createMongooseDataSource(connection, { flattenMode: "auto" })
);
agent.customizeCollection("Team", (collection) =>
  collection
    .addAction("increase size", {
      scope: "Single",
      execute: async (context) => {
        const { size } = await context.getRecord(["size"]);
        await context.collection.update(context.filter, {
          size: (size || 0) + 1,
        });
      },
    })
);

Setup of the workspace:

image
image1182Ă—582 18.6 KB

Note that the workspace list only shows “name” and that the field below shows the “size”.

Repro Steps

  • Load the workspace
  • Select the first record on the list - shows the correct size on the field below
  • Activate the action “increase size” from the “actions” dropdown
  • The “size” field shows the old value still - in the DB the new size already exists
  • Select another team - then go back to the modified team.
  • The size fields reflect the new value now.

Untitled ‑ Made with RecordCast

4

Hello @Yoad_Snapir

Thank you for this hightly reproducible setup !

Do you see an error in the browser console ?

5

I cannot spot any error relevant to this, maybe I am missing something (You refer to console errors or error HTTP responses?)

6

Hello

If you also have http errors, you can send both, but I mostly want to check the console errors

Thank you

7

Understood @nbouliol - No Problem.
While reproducing the above - at no stage did I have any console errors.
All HTTP requests (To the agent backend or Forest Api endpoints) completed with 200/204 - so no errors there as well.
Hopefully this moves us closer to a resolution.

8

Hello @Yoad_Snapir,

Thanks for the added details, we managed to reproduce the issue.
We have opened an ticket on our side and started working on a fix.
We will keep this thread updated !

Have a nice day,

@Nicolas.M

1 Like
9

Hey @Yoad_Snapir,

A fix has been released, everything should work now :slight_smile:

10

Seems like indeed it’s solved (Entire modified record is reloaded!)
Thanks for the quick response!