Read Locked Data entry in Module History

I'm looking at the File -> Module Properties -> History tab and no matter how I want to view the history (Sessions, All, Module) I notice one entry that simply reflects "Read Locked Data". Since I'm the Database Administrator and have Admin access to everything in the DOORS database, this entry is confusing. Under what circumstances would the DBA with Admin access to a module see this entry in the history? I only want to know so I can explain it to others. It would be awkward for the DBA to say, "I don't know what this is, and I don't know why I'm seeing it in the History record for this module".
I've searched through the Help files (which nowadays takes anywhere from half-an-hour and longer to find anything of value) and came up with nothing.

Chris Annal
SW Test Engineer / DOORS Database Administrator
Saab Sensis Corporation, East Syracuse, New York
chrisa@saabsensis.com
ChrisAnnal - Mon Oct 10 10:33:56 EDT 2011

Re: Read Locked Data entry in Module History
SystemAdmin - Mon Oct 10 10:49:32 EDT 2011

Are you logging in as a DOORS user with Database Admin rights or as the real Administrator? If just a DOORS user, then access rights apply to your account.

The read locked data can be due to attribute deletion, rename etc. See this entry:

https://www-304.ibm.com/support/docview.wss?uid=swg21395616

Re: Read Locked Data entry in Module History
ChrisAnnal - Mon Oct 10 12:41:30 EDT 2011

SystemAdmin - Mon Oct 10 10:49:32 EDT 2011
Are you logging in as a DOORS user with Database Admin rights or as the real Administrator? If just a DOORS user, then access rights apply to your account.

The read locked data can be due to attribute deletion, rename etc. See this entry:

https://www-304.ibm.com/support/docview.wss?uid=swg21395616

Thanks Pekka!!
Logging in as the Administrator account allowed me to see the record that previously showed only "Read Locked Data". Oddly, that record was from a session that I had, involving the creation and deletion of a DXL attribute. I still think there's something buggy in the way this record was displayed (since I was the user and had all the appropriate access to the attribute that I created/deleted), but logging in as Administrator did the trick. Thanks!!

Chris Annal
DOORS Database Administrator / SW Test Engineer
Saab Sensis Corporation, East Syracuse, New York
chrisa@saabsensis.com

Re: Read Locked Data entry in Module History
llandale - Mon Oct 10 17:18:15 EDT 2011

ChrisAnnal - Mon Oct 10 12:41:30 EDT 2011
Thanks Pekka!!
Logging in as the Administrator account allowed me to see the record that previously showed only "Read Locked Data". Oddly, that record was from a session that I had, involving the creation and deletion of a DXL attribute. I still think there's something buggy in the way this record was displayed (since I was the user and had all the appropriate access to the attribute that I created/deleted), but logging in as Administrator did the trick. Thanks!!

Chris Annal
DOORS Database Administrator / SW Test Engineer
Saab Sensis Corporation, East Syracuse, New York
chrisa@saabsensis.com

Years ago someone rightfully complained that users that lacked read rights to an attribute could still query History to see its values. Telelogic then implemented the notion that if the user lacks read rights to the attribute right now then the history is read-locked for that user. Well, if that attribute doesn't exist then technically the user lacks read rights to it. It would be VERY difficult to implement some notion of who had read-rights when an attribute was deleted or renamed; and even if they did they would still need to be able to deny it in the future.

I suppose its possible that they could implement the notion of ghost attributes, whose purpose is only to provide access rights to that attribute's History. Or maybe they could query all existing attributes accesses, and if the current user has read access to them all then they could have read-access to other's in History.

  • Louie

Digressing, in DOORS v4 that contained an invisible "Users" module, and I noticed that while the password attribute was read-disallowed, I could still query History with DXL and see that attribute's before-after values, and therefore could get most folk's passwords. Told QSS thinking I was the first to discover it. I was not.

Re: Read Locked Data entry in Module History
ChrisAnnal - Tue Oct 11 08:02:49 EDT 2011

llandale - Mon Oct 10 17:18:15 EDT 2011
Years ago someone rightfully complained that users that lacked read rights to an attribute could still query History to see its values. Telelogic then implemented the notion that if the user lacks read rights to the attribute right now then the history is read-locked for that user. Well, if that attribute doesn't exist then technically the user lacks read rights to it. It would be VERY difficult to implement some notion of who had read-rights when an attribute was deleted or renamed; and even if they did they would still need to be able to deny it in the future.

I suppose its possible that they could implement the notion of ghost attributes, whose purpose is only to provide access rights to that attribute's History. Or maybe they could query all existing attributes accesses, and if the current user has read access to them all then they could have read-access to other's in History.

  • Louie

Digressing, in DOORS v4 that contained an invisible "Users" module, and I noticed that while the password attribute was read-disallowed, I could still query History with DXL and see that attribute's before-after values, and therefore could get most folk's passwords. Told QSS thinking I was the first to discover it. I was not.

Thanks, Louie. Your explanation makes sense to me. I see the importance of protecting data from eyes that shouldn't see it, and since the Administrator can ultimately read those records, I'm happy with how this works.

Thanks!

Chris Annal
DOORS Database Administrator / SW Test Engineer
Saab Sensis Corporation, East Syracuse, New York
chrisa@saabsensis.com