Expose rank as a writable field in no-code automations

Maybe just when holding Option?

Im trying to template using lookups and triggering on link, but for some reason its not creating them in the rank as it is in the template… its creating it by creation date.

I have no idea why it does it this way, maybe in the way it sorts the lookup under the hood?

This would be easily solvable if I could just set the rank to equal the rank from the template.

1 Like

If multiple entities are linked simultaneously, the execution order for automations (triggered based on the entity linked to trigger) is not deterministic, so I don’t think you should expect the rank order of the link items to be taken into account.

If you need determinism, then you probably need to add an ‘order’ field, on which the items can be sorted, and ensure this field value is transferred to the created entities.

There is no chance (or maybe 0.001% chance) that rank will become an editable field I’m afraid.

What do you mean here? I don’t understand. Its just random? It seems to be maintaining the order of the creation date, so it doesn’t seem to be random… but im not sure.

Unfortunate! It’s exposed in scripting. Even maybe as a hidden field just exposed when holding option? It would really help :))

I mean that the order is not specified/guaranteed, and cannot be controlled/enforced.

1 Like

You should be able to do that in javascript.

True, but I’m reluctant to reach for scripting as its more fragile than the no code automations. If naming changes, the script breaks. I’ll try playing around with it and see if I get it work in non-fragile way. Maybe getting the names from the inputted entity rather than hard coding them. Will share findings here.

Even though it’s possible to set the rank number via scripting, it’s not recommended, and it wouldn’t be wise to create entities to have the same values as existing entities.

What about if it’s set to the rank of the other one, plus 1.or plus 100? Then it’s not the exact same but maintains the same order.

But then all tasks created with this template will have the same rank…

What if it was the rank of the other one, plus the public ID of the project it created, times 100. This way each one is unique, but maintains order within the project.

Public Ids are text type :face_with_diagonal_mouth:

But I suppose you could convert text to number.

I’m not going to recommend any particular method involving rank, because I don’t know the consequences.

I’d simply suggest using a dedicated ‘Order’ field instead.

Note: it is possible to use a formula field to get the relative position of a child entity in a collection:

(Find(
  [Project].Task.Sort().Join("#" + Right("000" + [Public Id], 4), ""),
  "#" + Right("000" + [Public Id], 4)
) +
  4) /
  5

See here:

(posted before you edited your post above)

:sob::sob::sob:

Never understood why this is.

Do you see any possible solution to this? I really don’t want to go the route of a manual sort field… It makes it clunky to resort things. Not ideal.

It consistently creates in the “created date” order. So some thing there (I feel like) is consistent…

Usually you come up with the craziest ideas haha.

Is my situation clear in what I’m try to get at? It’s hard to call it a “template” if it doesn’t copy the sort order. And right now this is the most clean and robust way to make templates in Fibery.

(after your edit)
Okay makes sense. I’ll try some things and see what happens haha

Scripting works. Doesn’t cause any issues (that i could find) with having the same rank in multiple places, just puts things next to each other in the views, and recalculates automatically when dragged. This is the cleanest solution for the end user.

Down side is the fragility of scripting. Changes in naming fields, space, or database will cause the script to break so i try to avoid scripting when I can. Hence, keeping this feature request open.

Another down side is the fact that newly created tasks don’t go the bottom, instead they are in the middle of everything. I didn’t implement the calculation based on the project id. This could solve it, but I’m more worried this would break things. If the number is too small or something? Could give it a shot and see what happens haha

Got it to work! But its making rank number a lot smaller than usual, so far it doesn’t seem to be a problem! Here’s the script:

// Developer reference is at https://the.fibery.io/@public/User_Guide/Guide/Scripts-in-Automations-54

// Fibery API is used to retrieve and update entities
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) {
    // an entity contains all fields apart from collections;
    // to access a field refer to it by its UI name
    const taskTemplateId = entity['Task Template']["Id"];
    const taskTemplate = await fibery.getEntityById('Project Management/Task Template', taskTemplateId, ['Order', 'Type 1']);
    const taskTemplateRank = taskTemplate['Order'];

    const project = await fibery.getEntityById('Project Management/Project', entity['Project']['Id'], ['Public Id']);

    const projectId = project['Public Id'];
    console.log(taskTemplateRank);
    console.log(projectId);

    const newRank = Number(projectId + String(taskTemplateRank))*1000;
    console.log(newRank)
    // to update an entity provide an object with the new values
    await fibery.updateEntity(entity.type, entity.id, {
        'rank': newRank,
    });
}

The down side is that after a certain number of moves it needs to reorder all the cards and assign new ranks. Not sure how long this would take is the database is very large… Could just make the *1000 into *1000000 to accommodate more moves. but still at some point it’ll need to rerank.

Updated:

// Developer reference is at https://the.fibery.io/@public/User_Guide/Guide/Scripts-in-Automations-54

// Fibery API is used to retrieve and update entities
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) {
    // an entity contains all fields apart from collections;
    // to access a field refer to it by its UI name
    const taskTemplateId = entity['Task Template']["Id"];
    const taskTemplate = await fibery.getEntityById('Project Management/Task Template', taskTemplateId, ['Order', 'Type 1']);
    const taskTemplateRank = taskTemplate['Order'];

    const project = await fibery.getEntityById('Project Management/Project', entity['Project']['Id'], ['Public Id']);

    const projectId = project['Public Id'];
    console.log(taskTemplateRank);
    console.log(projectId);

    const newRank = Number((projectId + String(taskTemplateRank * 1000000000000000)).substring(0, 15));
    // to update an entity provide an object with the new values
    await fibery.updateEntity(entity.type, entity.id, {
        'rank': newRank,
    });
}

Edit: the problem with the above is that a ranking of 10 and of 1 will look the same. working script below:

// Developer reference is at https://the.fibery.io/@public/User_Guide/Guide/Scripts-in-Automations-54

// Fibery API is used to retrieve and update entities
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) {
    // an entity contains all fields apart from collections;
    // to access a field refer to it by its UI name
    const stageTemplateId = entity['Stage']["Id"];
    const stageTemplate = await fibery.getEntityById('Projects/Stage', stageTemplateId, ['Order']);
    const stageTemplateOrder = stageTemplate['Order'];

    const project = await fibery.getEntityById('Projects/Project', entity['Project']['Id'], ['Public Id']);

    const projectId = project['Public Id'];

    const paddedOrder = String(stageTemplateOrder).padStart(3, '0');
    const newRank = Number((projectId + paddedOrder + '0'.repeat(12)).substring(0, 15));
    await fibery.updateEntity(entity.type, entity.id, {
        'rank': newRank,
    });
}
1 Like

This is an issue for my client’s templates as well to.
Subtasks on projects need to come across in order because they are in order of the project’s workflow. However we cannot set a sort field because one off tasks are added and need to be ordered. It is too hard for some users to look up a value and set a sort value on a new task for it to sort appropriately. They need the ability to drag an drop the subtask in the order of all the other subtasks. The only way this happens is if the subtasks maintain the sort order of the template. If scripting is there is no solution to this for the basic subscribers.

If this is already editable with scripting, why can’t this be edible on automations? This really is only needed when an entity is created during an automation.

Either way, is there another way to configure project templates so that tasks are ordered the way they are ordered in the template, while also continuing to support the end users ability to drag and drop us?

I don’t need to edit rank if templates worked this way.

Are you talking about a Fibery gallery template, or something you/someone else developed?

This would be a project “entity” template that we created as an entity in Fibery. Here is more context:

DB Settup

Templates, Projects, and Tasks are configured in the following way:

  • Projects can be though of as a parent task (although there are other differences to tasks)
  • Tasks can be liked to a parent task or a project.
  • Templates can be linked to a many tasks or projects.
  • Project and Tasks can only have one Template.
  • Tasks reference other Tasks, and Templates reference other templates in a one to many relationship, such that sub-templates mimic task templates and the parent template is the main task or the project.
  • This allows for templates and tasks to have an infinite hierarchy of child tasks (Like asana).

This is what the template looks like to the end user.

When a new project is created or linked to a Template several automations trigger.

  1. The first is on the project, which will pull in all the details on the template (such as name, description, etc)

  2. The second automation pulls in the subtasks. The way it works is when a project or task is linked to a template, and that template has sub templates, the sub templates see that addition through a lookup and this triggers a subtask to be created and linked to the Project or Tasks.

I had a look at the example (thanks for sending the template @danielbmarsh) and I can see the issue here.
There may be a potential solution by introducing a relationship which allows encoding the order of tasks within the same project (a 1:1 self-relation: Previous - Next using the idea described here) but it would probably be a bit clumsy, and might lead to loop detection triggering.
Alternatively, you can just add an editable ‘priority’ field to the template items, and then copy this to the created items, and sort on this value after they have been created.

I agree that there is potentially a need for users to be able to adjust an entity’s position programmatically, but I still think it won’t be implemented in the way of allowing users to edit the rank value directly.
I say this because of the way rank works which means we probably don’t want users directly adjusting the values.
Maybe we need to consider adding an action in automations to allow for ‘moving position’ of an entity relative to another entity. I haven’t thought deeply about how this might work, or what it would look like though.

And to be clear, i can’t imagine we will get to doing this any time soon, unless there is a massive spike in demand for this functionality.

@danielbmarsh are you able fix it with scripts? It’s working quite nicely on my workspace I set it up for.

Still think exposing rank in automations would be better for cases like these, but until then, it’s working with scripts.

Another solution to this problem would to have the lookup automation trigger to be deterministic based on rank, or setting a way to “sort” the order at which it runs the automation. Based on what field.

Rank is not a typical number field, so exposing it and allowing it to be editable via UI would be a right headache.

I’m not sure this would not work, at least for the example Daniel shared with me. Each Task is being created due to a (single) Template getting linked to a new (single) Project entity. So each automation is running for a different entity, and so although they are triggered simultaneously, they have no awareness of each other’s existence.
I suppose there could be some cleverness on the automation engine backend which looks at a load of triggers which arrived simultaneously, and compares the rank for each of the triggering entity, but this would be a universal thing for all automation executions, not something that could be set per rule.
But in reality, I suspect there is not really any such thing as simultaneity for automation triggers, only t2 - t1 < Δ

TLDR it’s complicated

I’ll try this today. The problem I will have however is that not all my clients are on Pro. So scripts are only a partial solution. I am excited to try it though.

I have a bunch of ideas here. Fibery’s rules engine is powerful in some use cases, but it also really limited when compared to some enterprise solutions. I keep meaning to do a writeup on this, just haven’t had the time, but I’ll think I’ll do something this weekend. Anyway here are a few ideas:

  • Enhance automations, the reasons my automation works the way it does is due to automation limitations, I needed to write 4 rules just to make templates work, in reality it should be one workflow rule. (I’ll post a writeup here later)
  • Instead of defining the actual value that rank is maybe allow a formula to use for the rank to considered on creation. This could be applied to the database as a whole rather than in an automation, and it would be more like the sort settings on a view rather than defining actual values
  • Rework sort so that a sort can be applied, but a user can still rearrange cards