"Ask User for Input" from script button action?

Hi community,

(Relatively) new to fibery over here, and in the preliminary process of moving my (small) org over from Coda.

I’m wondering if there’s a way to either A) query for user input via a script action triggered by a button, or B) easily pass queried information into the script

Thank you!

Not directly, that I know of. A bit of a hacky workaround that is do-able though is to create some kind of dummy field that will temporarily hold the user’s value. Thankfully you can hide these fields now in the UI, so it doesn’t have to be visible to the user. Then you get the value of that field using the built-in args in the script.

Steps:

  1. Create a new temporary text field to put user data into, I called mine “Prompt input
  2. Create your button, but make first step be to update the “Prompt input” field
  3. As the value to set, click on the ellipsis of the field to the right and select the “Ask user
  4. Add another step, this being your script
  5. In the script, use the entity in args to read the extra field (Prompt input), and there you have the value

In your case, you just need to read the available args.currentEntities property to get the current entity, then access its value (currentEntities is array, not sure why):
const userValue = args.currentEntities[0]["Prompt input"]

This updates the name of the entity you used the button on:

const fibery = context.getService('fibery');
for (const entity of args.currentEntities) {

    // Update 'name' to be new value, and reset prompt field
    await fibery.updateEntity(entity.type, entity.id, {
        'Name': entity['Prompt input'],
        'Prompt input': null // Reset the temporary container
    });
}
1 Like

Agree.
Interested to hear what @billyjackson needs to use the entered information for…does it have to involve a script? Or could it be done with actions and formulas?

This is phenomenally helpful, thank you very much!
With regards to getting user input:
In the case that I need multiple different types of User input (for instance: Assignees and Due Date) do you know if it’s possible to store multiple different kinds of data in a single field as an abstract (JSON?) object, or would I need to create separate fields for each?

@Chr1sG
Maybe it doesn’t have to involve a script! I’m quite new here.
From a Database Entity for “Documents” (an entity that - while similar to the native Fibery Document rich text feature - is distinct in that it can A) have additional metadata and B) doesn’t have to live inside the sidebar), I’d like to create an automatic feedback loop with a button “Get Feedback” that does the following:

  1. Prompts the user for who they need feedback from and when they need it by
  2. Creates a new task assigned to them with that due date
  3. Creates an inline mention of the Proposal inside the Task’s rich text description field
  4. Subscribes the user who pushed the button as a “Follower” on the task that will trigger an automation to notify them when that task is complete.

The rub here is that I’d prefer the Task not be hardlinked to the Document via a relation field. Some Documents belong to tasks (i.e. their information was created in the course of completing that task), but that’s not the case here.

Very open to alternative solutions, and thank you both!

Everything except creating the inline mention is possible without using scripts I believe.
What is the reason for wanting a mention in the Task?
I’m not sure why you’re reluctant to use a structured relation between Task and Document databases.

You know that you can have multiple relations between two databases (that represent different semantics)? In other words, could you have a (to-one) relation between Task and Doc called ‘Doc requiring feedback’ and also have a (to-many) relation between Task and Docs called ‘Output Documents’?

Hmm… I suppose my hesitation is out of a sense of overloading my apps with structured relations out of a (misguided?) fear that it’ll eventually create a bog-down. Am I worried for nothing?

Additionally, it’s difficult to point the feedback-giver to the original document without an additional list inside the Task entity. I figure a quick clickable link in the Description gets people where they need to go fastest.

I suggest the following will get you close:

  • the Task database should have a (to-one) relation to the User database, called ‘Reviewer’, say.
    I assume the Task DB has Due Date and Workflow fields already.
  • create a relationship between Document DB and Task DB (one-to-many I presume). From the Document DB side, this field can be called ‘Review Tasks’ and from the Task DB side this field can be called ‘Document to be Reviewed’.
  • add a lookup in the Task DB to get the author of the Document (i.e. ‘Document to be Reviewed/Created By’)
    If appropriate, these fields can be hidden on the entity view for either/both databases to avoid UI clutter*
  • create a button automation in the Document DB, which will add a linked Review Task. The fields for the Due Date and Reviewer can be configure to ‘Ask user…’
  • create an automation rule in the Task database which will run when a Task is completed. The action will be Notify Document Author (i.e. the lookup field created in step 3).

*The only thing that is not covered is the inline mention, but my suggestion would be to hide the ‘Document to be Reviewed’ field on entity view, but enable it as a pinned field (with ‘Show empty Field values’ turned off so as to minimise clutter).

WDTY?

1 Like

This is a pretty great solve, the only trouble I would have with this is that I’m hoping to preserve showing empty fields, because at present I’m keeping some of the more frequently accessed “tasking” features in there. The UI benefits there are enormous; it’s so quick to make those the most commonly accessed task features.

I think I may end up with a hybrid of your and Haslien’s solutions. I’ll fear-not the structured relation, but will use scripting to pop an entity mention into the description of the task.

Thank you again!

1 Like

Replying here with my final solution for posterity, in case anyone in the future searches the forums wondering the same thing:

I ended up combining @Chr1sG and @Haslien 's solutions into the following automation:

The Document item has a Relation to Tasks called “Feedback Requests”

There is a button - “get Feedback” that first runs the following action:

And then step 3 is the following script:

const fibery = context.getService('fibery');

    // affected entities are stored in args.currentEntities;
    // to support batch actions they always come in an array
for (const entity of args.currentEntities) {
    
    //Determine the markdown for the Document entity reference
    const schema = await fibery.getSchema();
    const dbID = schema['typeObjects'].filter((obj) => obj.name == `Resources/Document`)[0]['id'];

    //Define the content to be added to the rich text field
    const doccontent = "Provide feedback for [[#^" + dbID + "/" + entity.id  + "]]";

    //Get Current Doc's Feedback Requests
    const thisdoc = await fibery.getEntityById(entity.type, entity.id, ['Feedback Requests']);
    

    // get the rich text field "Canvas" of the last Feedback Request
    const linkedTask = await fibery.getEntityById("Project Management/Task", thisdoc['Feedback Requests'].slice(-1)[0].id, ['Canvas']);

    //Add current user as follower
    await fibery.addCollectionItem("Project Management/Task", thisdoc['Feedback Requests'].slice(-1)[0].id, "Followers", args.currentUser.id)

    // proceed if Canvas returned
    if (linkedTask['Canvas']) {

        const dsc = linkedTask['Canvas'];

        // set the rich text field contents as markdown
        const doc = await fibery.setDocumentContent(dsc.secret, doccontent, 'md');

    }
}
4 Likes