![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Triggering on a Module Save (not Attribute change) Topic Summary: Created On: 2-Jul-2004 00:01 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
Hi,
One thing I've always dreamed of was to find a way to Trigger a DXL (which sends an Email) when a Module was SAVED and find out what was changed by this Module SAVE. Any ideas? As we know: - The SAVE function in Trigger is just for an attribute "change", not a true Module/Attribute SAVE. - A User could make some Object changes Triggering a SAVE DXL (sending email of the latest value), but then the User may NOT SAVE the Module (just Close). The previous email is trash about the latest values. - If the User did change an Object and SAVE the Module, I could start a DXL on a Close, but how can I find what was really changed/saved by the Module Saved? I don't know what "time" the User opened the Module. If I did I could run some IF loops on History time and deduce the latest changes compared to the Current Time. Anyone have any ideas? I'm open for advice! Ben Note: I know how to use a batch job and send email message once a day (because of the "Last Modified On" with only day accuracy not seconds), but I'm looking for real-time Triggers. ------------------------- Ben Tooker |
|
![]() |
|
![]() |
|
Just some guess work here:
On module open: Fire a trigger that creates a file in a specific place named for the module+user On attribute save: Fire a trigger that stores the changes into the file created at open On module close: If the module was saved (or if it changed, not sure how to detect either!) create the email from the file you've been creating, then blow the file away. That's all entirely off the top of my head, and I'm sure you're going to give me some very good reasons why it can't be done, but there you go. Paul. ------------------------- Paul dot Tiplady at TRW dot com TRW Automotive |
|
![]() |
|
![]() |
|
Paul,
Thanks for the idea of the top of your head, but if the module was just CLOSED and not saved I don't wish to send the email. Like you said in you message "...not sure how to detect either..." (either a SAVE or just a CLOSE). I see what you're saying about the creating a "data file". That's a start. I'd probably put into the file the Object's Absolute Number, then when module SAVED go and find the "newest" value. Sometimes Users change the same attribute in an Object several times before a final Module Save, and I only want the latest/newest value. I may then need a loop reading the data file to find only the "latest change" to an Object and Attribute. But still, how can I figure out if the Module was SAVED or just CLOSED (if closed value if file useless.) Thanks, Ben ------------------------- Ben Tooker |
|
![]() |
|
![]() |
|
If you could get the "current" HistorySession for the module it would be easy; but you cannot.
You've got a problem since the user can use the Edit menu to switch edit modes without closing the module. Use a pre-module-close trigger. Get the most recent HistorySession for this module ("for hs in module do {") that you have reported. Loop through all History for the module, ignoring all those that whose HistorySession is less than or equal to the one you've already reported. Accumlate the largets HistorySession Summarize this History. Accumulate Summaries Send the Email, if any Summaries. Remember you've dealt with this largest accumulated Session. } You can store the latest HS for each module in environment variables, one for each module, but that gets messy and clutters up your Registry and won't Xfer to the next user. You could store all the latest HistorySessions for every module in some configuration file, but that gets messy and may produce a conflict when two folks close a module at the same time. This does not look easy. I'd be tempted to write something that runs at 11:59pm that finds all History today and Emails the relevant users. - Louie |
|
![]() |
|
![]() |
|
Louie,
Thanks for the analysis. I see the pre-module-close method. Then again my biggest problem arises a bit, What if the pre-module-close trigger was ignited but the module "Not Saved"? This is a occasional occurrence. (Note: The "for hs in module do {" would be providing data "closed", not "saved".) When you're dealing with near 30K requirements over 10 modules with numerous users its not desirable to have folks check the modules once an hour or so to see if something they-re responsible for has changed. I see the how 11:59 time frame has the folks notified one-a-day, but with this many requirements and a five level (domino theory) req structure, some req issues are desired to be resolved over a day or so (henceforth a real-time notification of changes) not a week, having a Level 1 req changed on Monday, appropriate folks notified/modifying a few Level 2s on Tuesday, appropriate folks notified/modifying a few reqs on Wednesday, etc... If Telelogic just had Module Properties with "Last modified On" to the common "one second" accuracy (that we see in every single object) this would solve my problem a bit. Then maybe once every 15 minutes of so I couple have batches run, noting an "accurate" Last Modified On time, then run a DXL to read changed modules and use "for hs in module do {" on these changed modules. Who knoes maybe Telelogic was trying to save some room on the Oracle and not save Module change times down to seconds ?!? (I don't see why Telelogic could not have a simple SAVE trigger.) Thanks, Ben ------------------------- Ben Tooker |
|
![]() |
|
![]() |
|
Could point about unsaved changes to a module. I hate it when that happens.
Your get-an-email right away scheme will clutter up InBoxes to the point that people ignore them. Real-time notification also presumes they WILL read the email right away; which doesn't seem to be true anywhere I've ever worked. I think you are better off with a Get-All-Recent-Relevant-Changes at one time approach. If once a day doesn't work then go for 10am, noon, 2pm, 4pm, and midnight. History and lastModifiedOn dates have only day-granularity (you can tell the day of the change but not the hour/minute) so it will get a little sticky, but your program could realistically keep track of notified changes and not report repeats. You could write a script that looks for changes in the last N days that are "relevant" to the current user; whatever that means. When the user is ready to check for changes she runs the script, types in N, and gets a report (or an email) of such changes. You could have an attribute-save trigger that sends the notfication; but you've still got the problem of not-saving the module afterwards. Very interested in how this works out. - Louie |
|
![]() |
|
![]() |
|
A thought: Can one check the history session number at module-close and compare it with the history session number at module-open to determine whether the changes will be/have been saved?
Another though: Would it be possible (in your process) to 'pull' the changes rather than 'push' them -- when a user opens a module, a trigger fires to check whether up-stream changes have happened? It doesn't seem like it from what you've said, but it may be something to consider... ------------------------- Paul dot Tiplady at TRW dot com TRW Automotive |
|
![]() |
|
![]() |
|
Louie and Paul,
I like the idea of checking the session at start then check when closing, but a session number isn't put into history until a module is saved. I have tried a scenario like this: 1. Open module, make a few changes (the history here points out a session 51). 2. Start a File/Close, initiating the Trigger. 3. In the dxl, I run a "for hs in current Module do" loop finding the newest in History (the session number 50). 4. The new changes at this current session, 51, aren't in the database (the history) until a SAVE is made. 5. The CLOSE Trigger is initiates the dxl before the "CLOSE or SAVE" box for a module is brought up. Thus, the dxl at triggered at CLOSE never had a chance to see the session 51 changes. 6. Then at the "CLOSE or SAVE" box if SAVE was selected, 51 would be in our nice history. If CLOSE was selected, session 51 changes would be thrown away. But all this after the dxl was triggered at the CLOSE. It would be nice if Telelogic, at a File/Close, would do a SAVE before a CLOSE. You know Trigger the dxl after the SAVE. Then I could just do some "h.oldValue and h.newValue comparisons". At a CLOSE trigger, I have even tried bringing up "my own" SAVE or CLOSE dialog box in the dxl. If the User says SAVE from my box, everything is stored in history nicely and I can use the "h.oldValue and h.newValue comparisons". If CLOSE was selected from my box I run the "h.oldValue and h.newValue comparisons" also to support the SAVE done before the Module was closed. (Note: I still keep the Module open.) Then a second after the dxl ends, the "normal operations" SAVE or CLOSE dialog box comes up. If SAVE was selected, no big deal just a bit more storing time. If CLOSE is selected no big problem, I got the data previously SAVED and Email sent. I just now have TWO dialog boxes one after another. I wish I could shut the normal operations SAVE or CLOSE box off. Some Users may get confused seeing two dioalog boxes one after another with the same question. Thanks for all these ideas I'm looking into them all deeply. Paul, I've even thought abit about pushing instead of pulling, but then who knows the next time that Module is opened in an editable mode after a change to pull a change or two. I'm going to keep looking. Respectfully, Ben ------------------------- Ben Tooker |
|
![]() |
|
![]() |
|
the "close(module)" command has an optional bool save parameter. Your code could look something like:
Module mod = current bool IsRead = isRead(mod) if (confirm("Save Before Closing")) save(mod) Do My clever History check stuff. close(mod, false) There is also a clever "setReadOnly()" Telelogic written function that downgrades the module to "R". I'd be tempted to use it before checking your clever history funciton; that way you KNOW no history can be saved or lost before you force a close. I think its worth trying. Don't know if your close command will fire up another trigger or not (and thus get an endless loop). If so, use IsRead to determine if you should force a close, or use set(preConPass). - Louie |
|
![]() |
|
![]() |
|
Paul, Louie,
My apologies, I haven't responded in awhile because of travel. I'll respond in about a week to you with a conclusion from your advice that works pretty well for me. Respectfully, Ben FYI: About a month ago I sent in a request to Telelogic. When I receive a response to this I will have it in the DXL Exchange. The following was the common Telelogic initial response: "Subject: DG2053819 trigger on module save event Ben Recently you contacted DOORS Support about using a Trigger on the event: Module SAVE. This request has been submitted, logged, and approved. We will contact you when this capability is available in DOORS. Regards, David" ------------------------- Ben Tooker |
|
![]() |
|
![]() |
|
The US support folks, wherever they are actually located, are not connected directly with the development folks who know what they are talking about in Europe. This is real bad news for those of us who already know more about DOORS than the support folks. Yup, they can help new folks do filtering and they CAN read the DXL manual, but they don't know squat about it. And if you don't push hard they'll just tell you what they do know even if its not relevant.
This forum will get you DXL answers much more readily. - Louie |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.