Refresh (F5) does not show changes by other users in shareable edit

For a module opened shareable edit by multiple users
Why does refresh not update the module to show changes made by other users ?
However switching edit mode does.

user case:
1.user 1 opens SRS module shareable edit
2.user 2 opens SRS module - locks section two
update object object text, save & unlock section
3.user 1 click F5 and does not see the change
Change to READ only mode, then chnage back to Edit shareable
The update by user 2 now shows
SystemAdmin - Tue Feb 14 14:39:37 EST 2012

Re: Refresh (F5) does not show changes by other users in shareable edit
SystemAdmin - Tue Feb 14 14:52:48 EST 2012

Neither Refresh (F5) nor Module Refresh (Shift + F5) update the module to show changes

Re: Refresh (F5) does not show changes by other users in shareable edit
SystemAdmin - Tue Feb 14 17:27:48 EST 2012

When you set up a module for Shareable Edit, the DOORS server breaks up the Module data into shareable chunks. I probably should have mentioned firstly that the DOORS database is a file based system, it's very primitive.

So, instead of one contiguous file, it breaks the module data up into multiple discrete files so that users can be given a write handle to the shareable file chunk that they want to work on. When you load up a module in Shareable edit mode, a read-only copy of all the chunks is passed to your PC, when you lock a section, the associated chunk is read again but this time you now have exclusive write access to that chunk.

The only way to view changes being made concurrently by others is to make sure that they have saved their latest changes, close the module and re-open it in Shareable edit mode, this should upload all of latest saved chunks. Another possible way, is to ask a user working on a section that you want to have a look at to save their changes and unlock, then you can lock that section which will force the associated file chunk to be read again with the latest saved changes. Messy ain't it?

A cautionary note - this breaking up of the Module data comes at cost to performance as DOORS has to open and integrate multiple files to build up the Module that you see on the screen. The more shareable sections, the more file chunks there are, the more time needed to construct and manage the Module. When you set up a module for Shareable Edit mode it will give you a warning prompt if the number of shareable sections could pose a major performance issue.


Paul Miller
Melbourne, Australia

Re: Refresh (F5) does not show changes by other users in shareable edit
llandale - Wed Feb 15 12:02:56 EST 2012

Yes, those refreshes updates your displayed module window with changes you've made. Since almost all of those changes are automatically displayed, the refresh is useful only in a few situations.

Yes, too bad there is no "re-read-from-database" command for open modules.

Yes, if you close and re-open you get the latest from the server. But if you have it open shared and you know your buddy just changed and unlocked a section, you can lock that section which will of course retrieve the lastest from the DB (of that section).

-Louie

Re: Refresh (F5) does not show changes by other users in shareable edit
BillTidy - Thu Feb 16 09:57:25 EST 2012

This doesn't answer your immediate question but maybe you will alter your approach to DOORS.
You need to ask why several people are working concurrently in 1 module. Usually you'll want to have 1 module ~= 1 specification ~= 1 product component ~= 1 work package. For 1 product component I'd expect 1 person is responsible. Even if >1 person is responsible I'd expect them more to be updating different attributes of the same objects rather than working on different sets of objects completely (ie different chapters).
It tends to be the case, that requiring shared edit for concurrent updates in different chapters means that you are specifiying >1 component in a DOORS module meaning you're specifying >1 work package in a document. I wouldn't recommend that. Instead, look at how your specifications relate to product components and how those requirements specifications relate to test specifications. Having a different mapping of DOORS Modules to product components and responsibilities for specifying/testing them will probably mean you never need to use Shareable Edit mode (which as you have seen is not a very optimal solution).

Re: Refresh (F5) does not show changes by other users in shareable edit
llandale - Thu Feb 16 16:44:02 EST 2012

BillTidy - Thu Feb 16 09:57:25 EST 2012
This doesn't answer your immediate question but maybe you will alter your approach to DOORS.
You need to ask why several people are working concurrently in 1 module. Usually you'll want to have 1 module ~= 1 specification ~= 1 product component ~= 1 work package. For 1 product component I'd expect 1 person is responsible. Even if >1 person is responsible I'd expect them more to be updating different attributes of the same objects rather than working on different sets of objects completely (ie different chapters).
It tends to be the case, that requiring shared edit for concurrent updates in different chapters means that you are specifiying >1 component in a DOORS module meaning you're specifying >1 work package in a document. I wouldn't recommend that. Instead, look at how your specifications relate to product components and how those requirements specifications relate to test specifications. Having a different mapping of DOORS Modules to product components and responsibilities for specifying/testing them will probably mean you never need to use Shareable Edit mode (which as you have seen is not a very optimal solution).

This is a reasonable argument for "Document Work Packages", but even so its somewhat reasonable to have one engineer modifying requirements in section 3 while a test dude is adjusting the test relationships in section 4.

There are other types of modules other than "Document Work Packages", and often you can have multiple folks editing them. For example, and interface spec where lots of folks have an interest.

-Louie

Re: Refresh (F5) does not show changes by other users in shareable edit
BillTidy - Fri Feb 17 10:42:18 EST 2012

llandale - Thu Feb 16 16:44:02 EST 2012
This is a reasonable argument for "Document Work Packages", but even so its somewhat reasonable to have one engineer modifying requirements in section 3 while a test dude is adjusting the test relationships in section 4.

There are other types of modules other than "Document Work Packages", and often you can have multiple folks editing them. For example, and interface spec where lots of folks have an interest.

-Louie

You don't put your tests into a separate module?

Re: Refresh (F5) does not show changes by other users in shareable edit
llandale - Fri Feb 17 14:23:18 EST 2012

BillTidy - Fri Feb 17 10:42:18 EST 2012
You don't put your tests into a separate module?

The tests yes, but traditional Section 4 includes the test traceability matrix.

In any event, lots of programs require shared access. Certainly the System Spec for the Enterprise will feature 5000 requirements, far too many for a single dude to manage.

But your original observation about working sets and responsibility is a very keen one.

-Louie

Re: Refresh (F5) does not show changes by other users in shareable edit
SystemAdmin - Mon Feb 27 17:54:00 EST 2012

Suppose we take shareable edit out of the equation.
Refresh & Module refresh seem pointless.

Scenario:
User one logs in Read only
Then user two logs in exclusive edit and adds a requirement, and updated the text for another requirement. He saves & exits the module.
User one clicks Shift F5 but does not see those changes.

Call me obtuse - but what is the point of module refresh, or view refresh
(they must each have different purposes since they are treated as separate functions)?

Re: Refresh (F5) does not show changes by other users in shareable edit
SystemAdmin - Fri Mar 02 07:53:54 EST 2012

SystemAdmin - Mon Feb 27 17:54:00 EST 2012
Suppose we take shareable edit out of the equation.
Refresh & Module refresh seem pointless.

Scenario:
User one logs in Read only
Then user two logs in exclusive edit and adds a requirement, and updated the text for another requirement. He saves & exits the module.
User one clicks Shift F5 but does not see those changes.

Call me obtuse - but what is the point of module refresh, or view refresh
(they must each have different purposes since they are treated as separate functions)?

Refresh forces the recalculation of all DXL attribute values in the module.