Skip to main content
Completed

Multiple open projects and how to handle them

Related products:Software FactoryWindows GUIUniversal GUI
E
Moderator

In the SF it is possible to open multiple projects or project versions. For example you can open functionality for version 1.00 and version 1.10 of your branch. However you are able to edit both. Sometimes if you need to check something with older versions/different branches this can become very confusing and there is the risk of editing the wrong branch or project.

Multiple ideas:
 

  1. Do not switch the active project upon switching tabs
  2. Add some kind of colour (red) or a warning sign (red exclamation mark) to show the current tab is not part of the active project
  3. Make any tab that is not the active project read-only.
  4. Make it possible to switch all opened tabs to the latest version, with the click of a button
    Did this topic help you find an answer to your question?

    20 replies

    htimmermans
    Captain
    Forum|alt.badge.img+12
    I wouldn't mind having inactive (or better, any status other than development) versions of a project or branch made completely read-only. i have stepped in that pitfall before in the past, making several changes in templates, thinking I was working in a development version... A restore of the SF was the quickest fix that time.

    If one really needs to make changes to non development versions, changing the status of such version to development is always an option.
    Regards, Henri Timmermans Software Engineer @BAS Group
    Tom van Druten
    R
    2 people like this
    • Tom van Druten
      Tom van Druten
    • R
      Roy van Uffelen
    Jasper
    Superhero
    • JasperSuperhero
    • 678 replies
    • May 28, 2019
    In version 2018.3 we added a warning message when selecting a non-development version or switching to an open document for a non-development version. Hopefully this already helps to prevent you from accidentally working in an older version.

    E
    Moderator
    Forum|alt.badge.img+17
    • Erwin Ekkel
    • Author
    • Moderator
    • 766 replies
    • June 3, 2019
    This helps when checking something with an older version of the project/branch. This does however still leave the risk of changing something in the trunk, a different project or a different (active) branch.
    Robert Jan de Nie
    Thinkwise blogger
    Forum|alt.badge.img+5
    I think that editing versions that are not 'in-development' should be prevented at all times. There is usualy no reason a developer should want to change past versions. The only situation I can think of is applying a hotfix to an older version or something. But this is the exception, not the rule. If you want to do that, you can easily change the status of the old version to 'in-development' for a few minutes and then apply the change.
    Robbert van Tongeren
    Tom van Druten
    R
    3 people like this
    • Robbert van Tongeren
      Robbert van Tongeren
    • Tom van Druten
      Tom van Druten
    • R
      Roy van Uffelen
    Tom van Druten
    Warrior
    Forum|alt.badge.img+6
    Robert Jan de Nie wrote:
    I think that editing versions that are not 'in-development' should be prevented at all times. There is usualy no reason a developer should want to change past versions. The only situation I can think of is applying a hotfix to an older version or something. But this is the exception, not the rule. If you want to do that, you can easily change the status of the old version to 'in-development' for a few minutes and then apply the change.


    I strongly agree with Robert Jan.
    Instead of making your version go red (sometimes it will, sometimes it wont) or giving a message, I rather not be able to change anything in project versions other than "In development"; but I could agree if some other statusses should not become read-only, but those should be reviewed.

    Editing something in a previous, inactive, version is such a waste of time, and sadly it sometimes happens. 😑
    Robert Jan de Nie
    Jop ter Horst
    R
    3 people like this
    • Robert Jan de Nie
      Robert Jan de Nie
    • Jop ter Horst
      Jop ter Horst
    • R
      Roy van Uffelen
    P
    Warrior
    Forum|alt.badge.img+3
    • PimWarrior
    • Warrior
    • 63 replies
    • June 5, 2019
    Actually, the problem with the pop-up right now (telling you the selected version is not in development) is that it comes right at the moment when you make a deliberate decision to switch to another version. When you switch to another tab which automatically gets switched to another version (or whatever), the pop-up does not come up and you are still unaware you are in an inactive version
    Tom van Druten
    1 person likes this
    • Tom van Druten
      Tom van Druten
    Robert Jan de Nie
    Thinkwise blogger
    Forum|alt.badge.img+5
    It seems that there is a lot of agreement on ONLY being able to change project versions that are in development.

    I'd like to improve this suggestion further; when copying a project version, it should automatically change the status of the previous one to inactive, so that, from that point onwards, the old project version cannot be changed anymore.
    Alternatively, you could ask the user for a new status of the old (to-be-copied) project version.
    Tom van Druten
    Jop ter Horst
    E
    3 people like this
    • Tom van Druten
      Tom van Druten
    • Jop ter Horst
      Jop ter Horst
    • E
      Erwin Ekkel
    Tom van Druten
    Warrior
    Forum|alt.badge.img+6
    Robert Jan de Nie wrote:
    It seems that there is a lot of agreement on ONLY being able to change project versions that are in development.

    I'd like to improve this suggestion further; when copying a project version, it should automatically change the status of the previous one to inactive, so that, from that point onwards, the old project version cannot be changed anymore.
    Alternatively, you could ask the user for a new status of the old (to-be-copied) project version.


    One of the things i often do is change the default of the copy project vrs task. Make sure it goes + 0.01, instead of 0.10. Then I edit the task itself, to set the previous version to inactive.

    I'd say just add a BIT with: "Set old version inactive" default value = 1

    code:
    update project_vrs
       set status = 3
     where project_id                 = @from_project_id
       and project_vrs_id             = @from_project_vrs_id
       and @from_project_vrs_inactive = 1


    Pim wrote:
    Actually, the problem with the pop-up right now (telling you the selected version is not in development) is that it comes right at the moment when you make a deliberate decision to switch to another version. When you switch to another tab which automatically gets switched to another version (or whatever), the pop-up does not come up and you are still unaware you are in an inactive version


    This is exactly why I strongly agree on RJ's idea on preventing any changes to inactive versions. I have asked for this before (like 2 years ago) and until now there still isn't a good solution. The red project version isn't working well and is not enough, nor is the message Jasper wrote about, as you noted in your reply Pim.
    Robert Jan de Nie
    1 person likes this
    • Robert Jan de Nie
      Robert Jan de Nie
    Robert Jan de Nie
    Thinkwise blogger
    Forum|alt.badge.img+5
    I did it again. Including an IAM synchronization. 😞
    Jeroen van den Belt
    Administrator
    Forum|alt.badge.img+9
    The following idea has been merged into this idea:

    All the votes have been transferred into this idea.
    R
    Captain
    Forum|alt.badge.img+5

    For hotfixes a hotfix-status could be an extra option.

    Further completely agree that changing past versions is not something you should want.

    PS Other version control systems only store changes in a new version, whereas in Thinkwise you first create a new version and store changes in this new version, until the moment comes for creating a new project version. Switching from other version control systems to Thinkwise took some time in getting used to this.

    Jeroen van den Belt
    Administrator
    Forum|alt.badge.img+9
    The following idea has been merged into this idea:

    All the votes have been transferred into this idea.
    Jeroen van den Belt
    Administrator
    Forum|alt.badge.img+9
    The following idea has been merged into this idea:

    All the votes have been transferred into this idea.
    Robert Jan de Nie
    Thinkwise blogger
    Forum|alt.badge.img+5
    Jeroen van den Belt wrote:
    The following idea has been merged into this idea:
     All the votes have been transferred into this idea.

    I think this idea has grown a beard…

    E
    1 person likes this
    • E
      Erwin Ekkel
    Arie V
    Community Manager
    Forum|alt.badge.img+12
    • Arie V
    • Community Manager
    • 1030 replies
    • March 24, 2022

    We are training a bunch of new people who joined our project, and as a Product Owner I decided to participate in building a Project case from scratch. You won’t believe how many times my colleagues and me have been falling in this trap! It results in frustration with my developers as well as overall productivity loss.
     

    And this is only one of the quirks of the Software Factory that cause the platform to be too difficult to learn without experienced people by your side. The SF is not exactly supporting the whole Thinkwise platform strategy this way…

     

    @Jeroen van den Belt @Jasper Unbelievable and utterly disappointing that this Idea is open for almost 3 years without proper resolution! When can we expect a proper solution?

    Jeroen van den Belt
    Administrator
    Forum|alt.badge.img+9

    Hi @Arie V,

    We fully understand that you would like to see this idea implemented. We can assure you that we take this wish very seriously, it is high on our backlog for this reason. The status of the idea did not reflect this, so I updated it to ‘On the backlog’.

    In fact, we have recently started investigating a working method in which this situation will no longer occur. It's a little bit early to share any results yet, or to set the status to ‘Active’ since we haven’t started implementation. As soon as we have relevant (status) updates to share, we will of course share them in this topic.

    Arie V
    Community Manager
    Forum|alt.badge.img+12
    • Arie V
    • Community Manager
    • 1030 replies
    • March 29, 2022

    In fact, we have recently started investigating a working method in which this situation will no longer occur.

    @Jeroen van den Belt I've read about the versioning/branching concept change you're considering in the Release Plan 2022.2, which states nothing more promising but ‘During 2022 we will be exploring different options to improve this...’. That sounds as if at least another year will go by before we see the implementation of the new concept.

    In the meantime a fix is still very valuable. How hard can it be to simply set all screens to ‘Read Only’ for an Inactive Project Version? Would assume that isn't too hard with something like a Layout and Context procedure that is dynamically assigned and generated for all Subjects?

    Renée Evertzen
    Moderator
    Forum|alt.badge.img+4

    Hello everyone following this topic,

    Since we have recently released the 2022.2 version of the Software Factory, we have already started working on the new features for the 2023.1 release. One of these features is handling versioning in the Software Factory through temporal versioning.

    This means that we will do a complete revision of how projects and project versions are managed in the Software Factory, which also includes many of the issues discussed in all the comments above.

    A sneak preview on what we are planning on implementing can be found in the following blog:

    Once we are further along with the development we will present you with another blog with further details on the specific changes that will be noticeable by developers that use the Software Factory, so stay tuned 😄

    Hopefully this will bring some enthusiasm for the future!

     

    @Arie V , @Robert Jan de Nie , @Erwin Ekkel : I tagged you guys since you guys seem actively involved in this topic 😅

    Jeroen van den Belt
    E
    2 people like this
    • Jeroen van den Belt
      Jeroen van den Belt
    • E
      Erwin Ekkel
    Jeroen van den Belt
    Administrator
    Forum|alt.badge.img+9
    On the backlog→Next release
    Robert Jan de Nie
    J. de Lange
    2 people like this
    • Robert Jan de Nie
      Robert Jan de Nie
    • J. de Lange
      J. de Lange
    Mark Jongeling
    Administrator
    Forum|alt.badge.img+23
    Next release→Completed
    "Wake me up before you low-code" | On holiday 06-02 till 27-06

    Reply


    Terms & ConditionsCookie settings

    Cookie policy

    We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

     
    Cookie settings