Open

Multiple open projects and how to handle them


Userlevel 5
Badge +6
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.

14 replies

Userlevel 5
Badge +10
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.
Userlevel 6
Badge +7
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.

Userlevel 5
Badge +6
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.
Userlevel 5
Badge +3
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.
Userlevel 4
Badge +6
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. 😑
Userlevel 5
Badge +3
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
Userlevel 5
Badge +3
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.
Userlevel 4
Badge +6
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


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.
Userlevel 5
Badge +3
@Tom van Druten, I think you should be able to choose what the new status of the old project version is, it could also move on another phase of your development, i.e. TEST.
Userlevel 4
Badge +6
@Tom van Druten, I think you should be able to choose what the new status of the old project version is, it could also move on another phase of your development, i.e. TEST.

Even better 🙂
Userlevel 4
@Tom van Druten, I think you should be able to choose what the new status of the old project version is, it could also move on another phase of your development, i.e. TEST.
Like this?



This feature is already in since 2018.3 I believe.
Userlevel 5
Badge +3
@Robbert van Tongeren I'm getting old.... 👴
Userlevel 4
Badge +6
😥 We're still on 2018.2
Userlevel 5
Badge +3
I did it again. Including an IAM synchronization. 😞

Reply