![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Slow Accessing of Module - but for just one user Topic Summary: Created On: 24-Jun-2008 15:57 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() Answer: My first thought was the the user had a different default view to everyone else, but they don't. If not, its probably that this user has a custom default view, or some layout-attrDXL-trigger is somehow coded to recognize this user and do something special (open a bunch of modules). - Louie I had made this assumption because no other users apart from me have the access to change the default view, but they CAN change their own custom default, which I check AGAIN after your comment above. It turns out that they HAD changed their custom default to one that they shouldn't have used, as it slows everything down surprise surprise. The moral: don't let users loose AT ALL. Nail them down, bolt them down and, if necessary, lock them up in a darkened room. Thanks for all your input, sometimes another view is need to see he wood for the trees. | |
![]() |
|
Similar to an
old thread of mine, which was resolved when it was determined that the default view for the module included a processor-intensive script. In the latest instance, the same problem occurs for just one user, on only one module. If left for 20 mins it opens but has opened in the background a further 25-30 modules instead of the expected two. My first thought was the the user had a different default view to everyone else, but they don't. Everything tells me that this is another issue with a layout DXL script on the default view, but I can't understand why it doesn't happen for anyone else. Any ideas, anyone? |
|
![]() |
|
![]() |
|
Perhaps this user is the only one that has R access to the modules being opened. Perhaps he's the only one with access to some AttrDXL attribute in this or one of the two standard opened modules. If so, the Administrator should likewise experience long delays.
Its unlikely, but perhaps there's a trigger or layout or attrDXL that has this user especially coded to open these modules. Search the forums for 'DxlFind.dxl' which prints all the layouts-attrDXL-Triggers that may affect a module. Run it as the Administrator on the module in question. - Louie |
|
![]() |
|
![]() |
|
Louie, I found and ran the DxlFind.dxl script here https://forum.telelogic.com/customer/doors/messageview.cfm?catid=17&threadid=8889&highlight_key=y&keyword1=DxlFind
I get "-E- DXL: <Line:56> incorrect context for function call" which is the second line of this bit:- for trg in (current Project) do { if ((Item stored(trg)) != item(fullName(current Project)))continue if (DisplayTrigger(name(current Project), trg, "Prj")) FoundOne = true } This is using DOORS v7.1, I guess there's something that is 7.1 incompatible. Answering the other points, the user is part of a group that has RMCD access. Other users of their group open it correctly with no excessive module-opening. Also I have RMCDA. As far as I know, there are no triggers involved, as we don't use them. I can't imagine that this particular user would have set any up, as they are very much a novice user. |
|
![]() |
|
![]() |
|
Hi Alan,
Although you don't think that there is a trigger involved, I attached a small script which displays all triggers in the database, project and module and allows for their deletion. I am using it under Doors v7.1. Did you check the access rights on the two modules, too, which you expect to open in the background? What happens if the user opens them directly, does this open the 25 additional modules? Peter |
|
![]() |
|
![]() |
|
Very handy script Peter, and it confirms that there are no triggers at all in the database.
As for the two modules that open in the background, one is the largest in the database (which has been the cause of my concern in other threads). However, as this particular problem only occurs for a single user, I don't beleive that the background module is at fault. |
|
![]() |
|
![]() |
|
Guess DxlFind only works in v8.
Does the Administrator experience this problem also? If so, its probably that this user has unique R rights to some AttrDXL that's running in one of your 3 modules. That is, other folks cannot read the attribute and therefore cannot initiate its DXL. If not, its probably that this user has a custom default view, or some layout-attrDXL-trigger is somehow coded to recognize this user and do something special (open a bunch of modules). Albert made a good suggestion. Close all modules and and find out which of the 3 standard modules is causing the problem; do that by opening in turn each of the other two and see if that causes the hidden processing and opening of the other 25. At the same time you can check for a custom default view in these two modules, which is the most likely cause of your problem. - Louie |
|
![]() |
|
![]() |
|
My first thought was the the user had a different default view to everyone else, but they don't. If not, its probably that this user has a custom default view, or some layout-attrDXL-trigger is somehow coded to recognize this user and do something special (open a bunch of modules). - Louie I had made this assumption because no other users apart from me have the access to change the default view, but they CAN change their own custom default, which I check AGAIN after your comment above. It turns out that they HAD changed their custom default to one that they shouldn't have used, as it slows everything down surprise surprise. The moral: don't let users loose AT ALL. Nail them down, bolt them down and, if necessary, lock them up in a darkened room. Thanks for all your input, sometimes another view is need to see he wood for the trees. Edited: 25-Jun-2008 at 15:15 by Alan Gooch |
|
![]() |
|
![]() |
|
A good friend of mine once told me that a rolled-up newspaper can be useful in controlling difficult users. :-)
------------------------- Tony Goodman Smart DXL limited www.smartdxl.com |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.