Also agree here - I liked in Confluence the fact that you could revert to previous versions. The “Rich Text” field type functions similarly with you guys - although you have the advantage of this being an actual entity with all the great substance around entities! - so being able to revert to previous versions would be very useful and add some good wiki functionality.
Wanted to point this request out again. As a Fibery instance grows and more and more knowledge finds its way into the System, this is becoming a bigger need of ours. I think most other apps have this function, so would love to see it here. Would be grateful for any update on progress from the Fibery Team!
As an add-on to this request, when it’s implemented, I’d appreciate the ability to be able to make relationships that are version-specific.
Ideally, I can choose to create a link that is either:
- to the entity in general, independent of what versions exist
- to a specific version of the entity, including current version (but which may not remain current)
Hope you understand what I mean.
Woah, that’s an interesting but complicated-seeming addition. Can you give an example of where this would be useful?
One use case I had in mind was for test cases and their executions. If I write a test case, and then execute it, it would be great if the execution only linked to the version of the test case that was valid at the time of execution.
If I edit the test case, I don’t want the execution to link to the latest version.
Would love to see this type of sophisticated software dev capability in Fibery, but from my point of view could wait for it till later. Fundamentally though being able to see an activity record of Rich Text fields, and potentially revert versions would be great right now.
Coda has a great feature where you even get to back out during a session if you don’t want to save it when opening a Rich Text box. It auto-saves every few seconds, but you also get to “save” before you close the window, very convenient!
This is similar to Confluence I mentioned above.
I think some implementation of either of these would be very, very useful - I’d make great use of it right away!!
Interesting. I can imagine other possible approaches to this that seem less complicated to me from a dev and UI/UX perspective, but I’m curious to know more. Are the Test Cases and Executions both represented as their own Types?
Yes, I had assumed that using a type for Test Cases and a type for Test Executions made the most sense. If you have suggestions for how to solve the problem with fibery as it is, please let me know
I basically want to define a Test Case (as a series of test steps: “Do this”, “Measure that”, etc.) and a user can instantiate a linked Test Execution which contains the results of following the steps. If the Test Case is subsequently updated (e.g. remove the “Measure that” step) I don’t want the existing Test Execution to link to the revised Test Case, since they would be inconsistent. I want the Test Execution to link to the state of the Test Case at the time it was executed.
I suppose I could automatically copy the details of the Test Case into the Test Execution at the time of its creation, but that doesn’t seem to be a very graceful way of doing it. I’d much rather link to a historical version of the Test Case.
Gotcha. So to really try to resolve this I’d probably need more info, and you’re probably right that versioning would help create a more ideal solution. However, without knowing more, I can see at least two other possible approaches off-hand, aside from copying the test case into the execution entity (and there may be more with some more thought and/or knowing more about the workflow).
1: Define the test cases in a Rich Text field, with check boxes or whatever you prefer. And delineate each version with a header (H1), e.g. “Assembly test case #45 V1.0”. Then somewhere in the body of that section of the text, link to the Test Execution Entity for when you run that test. When you update the test case, copy/paste everything you want to update from it, create a new header “Assembly test case #45 V2.0”, collapse the previous one, and paste in the V1.0 contents and update. A little manual work, but not too bad, and you keep all the versions in one place.
I’ve shown a pseudo-example in the image below. Obviously I’m linking to the wrong entity, in this case the Test Case itself. You can see the previous test case is collapsed at the bottom. I just copy/pasted the bottom one to make the top.
2: Another option might be to create a “self” relationship in a 1:1 configuration for the “Test Case” Type and name the two resulting fields “previous version” and “next version”. Then when you need to update the test case, create a new version and link to it in the “next version” field, copy the contents of the old, go to the new, paste, and edit as-needed. Any Executions of that version of the Test Case get linked as normal in their own 1:1 relationship field. Again shown in my example image, this time outlined in blue, and obviously the relationship to “tasks” here in my test Type would for you be a link to the “Test Execution”.
Obviously all of these involve steps like copy/paste which you might see as being too much work for your needs. And these ideas may be totally non-workable, or just not an improvement on what you’re already doing. One thing I’ll say that I think this makes clear is that a “copy entity” function would be nice.
Part of what would be good to know to try to come up with better options is what really are the “pain points” of your existing workflow, i.e. what takes the most time/effort and what other problems arise from these versioning issues, how often does versioning happen, how many maximum versions are you likely to have, etc.
I’m also curious if any existing tools that you know of already handle this well and could be used as a good model.
Having said all that, I definitely want document history and possibly versioning, i.e. named versions. I’m just less confident about how to best handle the complexities of maintaining history on relationships, backlinks, etc.
I suppose one simple option for dealing with e.g. a deleted entity would be to maintain the name of it in any entities it was linked to, in their history state, and the live link just doesn’t work. Or, alternatively, to maintain a read-only archive of the deleted entity in the state in which it existed when it was linked from the version of the entity you’re looking at. But even trying to describe issues like this starts to make my head spin and is one reason I’m wary of wanting to rely on this kind of deep and complex version handling.
I’m glad I don’t have to actually implement solutions to these problems and trust that @mdubakov and team will make good choices moving forward. They have done well so far.
Very thoughtful response, thank you.
In the past, I have occasionally followed the #2. solution you described, and as you say, it becomes a whole lot more workable when there is a ‘copy entity’ function (+ ideally a ‘lock entity for edits’ to ensure the v1.0 is not accidentally used).
But yes, I can well imagine that there are many situations where being able to link to specific historical versions creates a lot of what-if questions. That’s probably why I’ve never encountered a solution that I truly love. Maybe I should not wish for this feature after all(!)
As a compromise, I have tried to implement a flag that would indicate if an entity has been changed since the last time it was ‘approved’ so that anyone viewing the entity can make a value judgement on whether or not any existing related entities are still valid, or if they also need updating. It’s sort of related to what some software tools implement as ‘Mark as suspect’.
However, the hassle of implementing this for every type where this kind of flagging would be useful has somewhat put me off.
(this is one of the reasons why I had previously suggested the possibility of Fields applicable to all types which I know generated a fair bit of discussion!)
As you have said (here and elsewhere) the fibery team seem to have a very good idea for what adds value and how best to implement, so I have also decided to hold off making major feature requests for the time being. Instead, I just look forward to seeing what they bring out and working out the ways it can be useful to me.
But I still love reading these forums to hear what challenges other people have and how they solve them
Yes, same! I always feel that a good community and the ability to have open dialog, even when there is some disagreement, is a really good sign.
One thing I love about it here so far is it’s very practical and work-oriented. There is very little over-the-top idolizing of the product or mysticism about its team. This may just be a product of the lower market penetration vs. e.g. Notion or Roam, but both those products have really annoying/unproductive aspects of their respective communities in my opinion (cult-like is a term that’s been used ).
So while I don’t wish for Fibery’s community to remain small as it is now, I do hope we can maintain the more realistic approach, open dialog, and helpful nature as it grows.
And @Chr1sG, I am curious how much either of you have dabbled in TargetProcess? There was an interesting Test Case module that I liked.
In a Fibery context, as far as I can tell, this would just be tweaking some attributes around Apps/Types to duplicate that functionality, but we don’t have the capabilities yet as some views are missing, and TargetProcess was all about hierarchy…yes, that subject again
On a broader level, I am hoping to see a lot of what Michael, presumably, conceived in TargetProcess soon in Fibery. Another great piece in there was Dashboards…hmm. While I’m at it, in fact a lot of what we’ve been discussing was handled very well in TargetProcess. Where I fell down in TargetProcess, and what Fibery solves, was the ability to more liberally relate items. You couldn’t do it there. The hierarchy was great, but that tool was all about top-down hierarchy I would day. The basic entities were cascading down in this data model:
You worked mainly within that. So if you wanted to create an Entity on the “task” level, it had to first be “sub” to a “user story” before relating up to the “feature.”
TargetProcess had “free” relations though, too, which were useful - you could see them on boards I believe. So we’re getting into our “polymorphism” discussion, too.
Let’s hope all of the good in TargetProcess makes its way over to Fibery ultimately!
I never tried TargetProcess, but I’ll probably have a look at it over the weekend
Great examples, thanks! Given Targetprocess handled this well, I have even more faith Michael and team will figure out how to address this kind of need (and much more) with Fibery.
Thanks guys @Oshyan and @Chr1sG for weighing in! Would love to hear your thoughts, I think you can run through the TP marketing site and get a good feel for it. Unfortunately they’ve gone Enterprise so no easy way to quickly get a demo account these days over there
If we could get the basics out of TP here in Fibery that we’ve been talking about - hierarchies, dashboards, better notifications, apps, simple relations, etc., my needs for Fibery would be 100% solved. I agree Oshyan that in principle I think the team here should be able to replicate that since in essence Michael was involved in that stuff. But candidly, I don’t see a lot of response to many of the suggestions I’ve posted around here, and mentions about stuff in TP and when we’ll see it here. If you have a look at some really good posts from @Shafqat_Ullah, who sadly I don’t see too active any more, he points out a ton of the good stuff from TP as I have assumed he was a longtime user. This very post is his in fact!
Thanks guys and very eager to get your thoughts on this particular point! I am still having a lot of trouble in Fibery with my team without these basics…so desperate to try to figure out when, or more nervously - if - they are coming!
And hey, have to agree 100% with the cult aura around both Notion and Roam, Roam worse I think. Neither of those tools doing much feature delivery of late either…
Hoping Fibery continues to delivery useful features, but would like to see more guidance around some “team” stuff I just mentioned that we’ve been discussing…
Not sure if you noticed (I often miss it), but I do believe Michael marked this as “Approved”, i.e. “we will implement this feature request” just a day or so ago. Of course that does not indicate a time line, but it’s a promising first step, and some “engagement” with the request, at least.
I would also say that, although they do not have a public road map, their dev pace and look-ahead (a month or two on each blog post) is a lot better than you get with either Notion or Roam, or a lot of other products. So while I totally get you wanting to have this ASAP, we don’t know when it’ll be, but it is at least “coming”…
This is implemented and released today.
Wonderful. Hopefully you can close this issue and release the votes!