CHANGELOG: October 1 / Create Documents and Whiteboards inside entities, Automatically link entities based on rules

We’re working on Integrations now, GitHub, Intercom and Trello will be released pretty soon. GitLab and Jira will follow next.

Create Documents and Whiteboards inside entities

Sometimes you want to attach several documents or whiteboards to an entity. For example, you have a feature and it would be handy to create technical specification in a document and draw flow diagram. Now you can do it, just install Documents and Whiteboards extensions. Here is how:

Automatically link entities based on rules

Now you can setup automatic relations based on some rules. It is mostly needed for integrations, but I think you will invent other interesting cases. Below we automatically link Pull Requests from GitHub to User Stories in Fibery.

For your convenience, here is the formula that extracts user story id from “fibery/us#123 some name”

If(StartsWith(Name,"fibery/us#"),Trim(ReplaceRegex(Name,"fibery\/us#(\d+).+"," \1 ")),"")

And here is the place where to enable the rule:

New Search for # (insert entity) operation

When you insert an entity into a document or rich edit field, you will enjoy the new search with filters:

4 Likes

I tried setting up a test of the automatic linking but could not seem to get it to work. I had a number field for type A and another number field for type B and defined an automatic relationship that would link A & B if the number values matched, but nothing seemed to happen.
Are there constraints or pre-requisites for how the linking works?

When the Documents extension is enabled, and is visible as a column in a table view, it’s possible to link any type of view to the entity (not just documents). The same seems to be true for the Whiteboard extension. Is this intended behaviour?

Also, it seems that the extensions provide a one-to-many relationship between entity and document/whiteboard, which means that a document can only be associated with a single entity. Is this going to remain true, or will it become many-to-many eventually?

I noticed that when I associate a document with an entity, the document disappears from the sidebar (I guess to be expected, now that it is ‘owned’ by the entity). However, unlinking the document does not make it re-appear, so it seems to become invisible.
I can tell that it isn’t permanently deleted, since it still shows up in the list of documents that can be linked to. It just seems like I can’t get the document back without giving it an entity as a ‘parent’.

1 Like

Judging from my experience with Trello, it offers nothing that can’t be done natively with Fibery, so why would you spend time to make an integration? Do you think that some of your (potential) customers are so committed to Trello that it would be a deal-breaker to expect them to use Fibery boards to achieve the same thing (and more)?

2 Likes

We’ve added Trello because it was 2 days work to test integration framework better. I do agree that there are not so many cases for it when people use Fibery.

1 Like

When the Documents extension is enabled, and is visible as a column in a table view, it’s possible to link any type of view to the entity (not just documents). The same seems to be true for the Whiteboard extension. Is this intended behaviour?

No, this is definitely not. Hotfix this coming soon :slightly_smiling_face:

Extensions provide a one-to-many relationship between entity and document/whiteboard, which means that a document can only be associated with a single entity. Is this going to remain true, or will it become many-to-many eventually?

Yes, we want to keep one-to-many relationship so that left menu will always be in sync with what you see on entity page

When I associate a document with an entity, the document disappears from the sidebar (I guess to be expected, now that it is ‘owned’ by the entity). However, unlinking the document does not make it re-appear, so it seems to become invisible.

We should not allow to unlink a doc from an entity so far - only to link from another entity. Fix for this is coming :slightly_smiling_face:

2 Likes

:frowning:
Shame, I thought it was nice to be able to link to any view

What’s the thinking behind this? Might it not be possible that a user would decide that a document needs to become ‘shared’ among multiple entities, in which case allowing the document to be moved from being ‘owned’ by a single entity to living at the app level (or allowing many-to-many links) would seem to be useful.

2 Likes

Might it not be possible that a user would decide that a document needs to become ‘shared’ among multiple entities, in which case allowing the document to be moved from being ‘owned’ by a single entity to living at the app level (or allowing many-to-many links) would seem to be useful.

That’s our next step. Yep, you’re right, supposedly that’s the way it will be working: unlinking a document lifts it to the app level :slightly_smiling_face:

2 Likes

Agree with this, was also surprised to see Trello, and also Jira - which I think was earlier revealed, because both of what these tools do I would be doing 100% in Fibery.

Other stuff on my list that Fibery/Trello/Jira can’t do:

  • so called “VCS” stuff - Github, etc. That’s obviously a big one, although would like to see at some point Bitbucket as we use that
  • Calendar integrations
  • Email integrations
  • Intercom
  • Figma

The last two were at the top of the integrations list as I understood some time ago, along with Github/Gitlab.

Thanks!

1 Like

I also have been playing with this and not sure how it works. What I was hoping for was a sort of “inheritance” of a field if related entities both had that field. So I was doing this with a “Project” entity, and a “task” entity. I related the two. Then selected a common field “Department.” What I expected was that this would mean if I created one of those entities within the other, and the one from which I created the other had the common field already filled out, the “created” entity would inherit that field. Does this make sense @Chr1sG?

What seems to happen though is when I do this, I get more of a Lookup-type field that can’t be edited. This doesn’t seem like an actual “relationship” as the update here would indicate, since Lookups aren’t actually relationships as I understand, ie you can’t use them in Boards because they won’t show as relating to the entity where they reside.

Would be grateful for some guidance here as this seems like a cool feature but I really don’t understand exactly what you are creating when you add “Automatically Link…” to a relation.

[EDIT: I have updated the app since this post was written, and it is now over here: Basic Test Management app and sharing seems to work now]

So I managed to make something useful using the automatic relations feature: a rudimentary test management app.
The idea is that a Test Case has several ordered Steps (with Action and Expected Result fields), and is linked to one or more Test Executions.
The Test Execution also links to a set of (ordered) Step Results (which have an Actual Result field, to be filled in by the tester when the test is run).
Then by auto-linking the Step Results to the Steps (based on the test case and order number) it’s easy to have a table view for each execution showing action/expected result/actual result for each step.
I also added a bit of logic so that it’s possible to see which execution is the latest for each test case, plus a summary report of all testing.

I hope people will have a play with it and give feedback.

[edit: I have tried to import the app into another instance of fibery and I get an error message:
image
so hopefully @mdubakov or the team can figure out what’s going on. I think it may be a bug in sharing apps that contain automatic relations]

For the next iteration, I was thinking of adding an action button for the Test Case (‘Execute Test’) which would automatically create a Test Execution and all the necessary Step Result entities, so that a tester only needs to enter the Actual Result data :slight_smile:

There are still some practical issues to be considered/fixed, such as how to handle changes to the test case after it has been executed, but it seems that versioning might be coming from the fibery team at some point, so I won’t try and tackle it just yet :slight_smile:

2 Likes

I would be very interested in seeing a Testing / QA app in Fibery, it’s the biggest hurdle that is preventing us from migrating from Targetprocess.

1 Like

Chris, interesting. A little outside of what I can digest in a quick read…

Curious though, have you figured out the basic functionality of this feature per my question below:

I actually didn’t see any true “inheritance” going on. That is, I thought if I had a field, say a multi-select, in one entity, and I linked it to the multi-select in another, the “linked” entity would pick up that value. That’s not happening for me. Was really hoping to get this working for inheriting relations in particular…

Thanks!

The things you’re describing seem to be achievable using Lookups, unless I’m missing something…either for inheriting field values or relations.
For example, if a Project type has a relation to the Dept type (or a multi-select/single-select field called Dept), and has child Tasks, then the Task children can lookup (= inherit) the Dept choice(s) from the Project, right?

OK thanks. Am I missing something, because when I do this, what I wind up with what appears to be a Lookup. As I mentioned, it’s uneditable, and unusable in boards. So if my intention is to make a relationship, and I then choose this newly-available “Automatically link Relation,” what I wind up with is an actual LookUp field that is, as far as I can tell, another “level” of lookup in that it will find these related Entities that are connected by the same field. There are not in fact related.

So keeping with the example we’re using:

If I have a Project

And I have a Task

I relate them…

And I link their common field “Department” with this feature

I get a “Department” field in my Collections area in my Task Entity, that looks like a LookUp to me. Since both “Project” and “Task” are many-to-one children of “Department,” this Collection will then fill in with whatever department the Project is Linked to. But this is not a relationship between Projects and Tasks, as this feature - judging by the way it is being presented - would suggest. This not “inheritance” by any means as I understand what “inheritance” is supposed to mean. Inheritance as I understand it is you have children that actually pick up the value of a field from the parent. In this feature, all that we are doing is showing the common field between the two related items. There is no actual auto association of fields between relations that you create between the entities in the relations when you create them.

This is all not to say that this isn’t a useful feature, it is! But I think it should be presented as a form of extended Lookup.

Thanks again!

Just so that I understand the example you’re making, Tasks are (many-to-one) children of Projects, right?

If Projects and Tasks are both children of Department, what should the behaviour be if a Project is moved from one Department to another? Should its tasks be automatically related to this new Department?

Anyway, here’s what I think auto-relations are useful for: they allow entities of one type to (automatically) be linked to entities of another type, based on one or more of their fields/links having the same values.

So, in the Test Management app I created, I have the following relations
image
There can be potentially dozens of Steps, but I want each Step Result to only link to the correct Step.

So I can link the Step Results to the correct Steps by using auto-relations where they are linked based on two criteria:

  • the parent Test Case for the Step = the grandparent Test Case for the Step Result (i.e. the parent Test Execution’s parent Test Case)
  • the sequence number of the Step = the sequence number of the Step Result

Now that Step Results are linked to the correct Steps, they can extract useful info from the Steps e.g. via lookups.

I think there are often occasions when it’s useful to create relationships automatically based on certain criteria. But that’s not to say that this mechanism is the right tool for what you would like to achieve :slight_smile:

Chris, thanks. Yes, as you state below:

That is exactly what I’d be expecting. As I understand the concept of “inheritance,” it means that one Entity/Record should keep the linked value with another, including when that value changes.

Other than that I’ll need to analyze your explanation in more depth, but as I was stating earlier, I still don’t see where this is more of a lookup feature than actual relation, because the linked relations do not show up in Boards as Rows/Columns available, which is a key part of Related Types as I’ve understood up till now.

Thanks again for the help!

In that case, I don’t see what the drawback is with the existing Lookups. Projects can be children of Departments, Tasks can be children of Projects, and Tasks can use a lookup to get the Department they are (indirectly) part of…
You can use lookups for rows/columns in board views, just like normal relations, but of course, you can’t move the cards between rows/columns, since the lookup is read-only, but from what you’ve answered above, it is the Project that would be moved from one department to another (and the Tasks would then be automatically moved).

Maybe we’re talking at crossed purposes… :-/

Hey I appreciate the help here.

Let me try this one more time as I feel like this is a very useful feature I just can’t quite figure out.

Here is the app in question:

I decided to use a “client” instead of the “department.”

So what I’d like to do is say I have a Project that I’ve already related to a Client. My Tasks have a relationship with the Client, too.

If I do this when setting up the relation:

This looks like a lookup Field.

How can I add a task to that project so that the new task, which is related to the Type “Client,” also gets the same value as the Project’s Client, which you can see there is already filled in with the “sample entity”

Thanks again for all the help!

I’m not sure why you have created a relationship between Clients and Tasks.
Presumably, a Task can only be a child of a single Project (which is a child of a single Client) and therefore creating a simple lookup (not auto-relationship) for the Task type allows each Task entity to have a ‘pointer’ to its Project’s Client.
You can use that ‘pointer’ in much the same way as a relationship field (filters, sorting, board rows/columns etc.) but it is of course read-only.
Given that I can’t see why you would want to change a Task so it is connected to a different Client than it’s parent Project, so I see no drawbacks.

Ok thanks. Yes I understand Lookups and they are useful, but I’m trying to accomplish something else: My Clients have both Projects and Tasks associated, so I need both to relate directly with Clients:

Sometimes, we do a quick one-off task for a Client, like “raise an invoice”

In other cases, we’ll run a full project, which will have a bunch of tasks. But those Tasks should be related to the Client as well. So if I want to see a report of all my Tasks related to that Client, that are either part of a Project, or are one-off, I can do that. This is where the “inherited” aspect comes in.

Another example would be a Conversation with a Client. This Conversation is a child of the Client because I will have many such Conversations with him/her. During that conversation, several tasks may come up. So those are children to the Conversation. But they are also tasks of that Client. Without inheritance, I am going to have to go back and manually relate those tasks to the Client. Again, I don’t want a lookup here as I want the direct relation.

I will play around with this some more on my own, but what I’m missing right now is a good explanation of how this works. Of the most surprise to me is that when you use this field to create a relation, the resulting relation is read-only, just like what you are saying about Lookups. I don’t expect relations to be read-only.

Thanks again!