I'd like to reset (re-arrange) all the Object Identifiers (ID) in an IBM DOORS module. I inherited the original description and would like to update the ID tags to have a better flow in the document.
Inherited
ID
Content
Req-55
Content A
Req-57
Content B
Req-14
Content C
Wanted
ID
Content
Req-01
Content A
Req-02
Content B
Req-03
Content C
It's important to highlight that I'm fully aware that each ID is linked to a database. I just want to try to figure out a way to have the ID tag better organized.
You should never give the DOORS "Absolute Number" of DOORS Objects a meaning besides the numbers being unique. DOORS gives you next to no means(*) to manipulate that number to use it for sth like a "flow". If you want an identifying number that has any kind of semantic, you will have to create a new Attribute which contains a manually filled identifier. With this, the user is free to e.g. create Requirement numbers e.g. in steps of 10 so that he can later add intermediate numbers, like
Manual ID
Content
Req-010
Content A
Req-020
Content B
Req-025
Content B.1
Req-030
Content C
(*) Well, if you really really really want to rearrange the objects as a one-time action and cannot sleep any more otherwise, you can only create a completely new Module, e.g. using Spreadsheet Export / Import, but this will result in the loss of all Links (which you will have to recreate somehow), all historic information like e.g. baselines, all permissions, possibly content like OLE objects and more. Prepare for nightmares.
Related
I have some rows in DOORS identified by a number. For example
Object Identifier
Description
1
description of object 1
2
description of object 2
3
description of object 3
4
description of object 4
I know if I want to modify an existing object, I just import an excel that has the columns Object Identifier and Description with the same number in the Object Identifier column, as the object I want to modify.
If I want to create new objects, I import rows with empty Object Identifier column. They get the identifier assigned automatically and will be inserted in the bottom of the table in DOORS.
But I want to modify some existing objects and create a new object specifically under the second object.
Object Identifier
Description
1
modified description of object 1
2
description of object 2
5
new object
3
modified description of object 3
4
description of object 4
How can I do this in one import?
I'm not aware of an official support for this. One method could be to have an additional column called e.g. "below". In this column, the excel editor might enter the object number of the parent object.
Then, after you imported your excel to DOORS, you would run a code like this, which moves every object where "below" is set, below the referenced parent object
Object o
Module m = edit … (or current or whatever)
Skip sk = create
for o in m do {
put sk, o, o
}
for o in sk do {
int iBelow = intOf realOf (o."below""")
if (iBelow) {
move o, below object iBelow
o."below" = ""
}
}
save m
As far as I remember while screwing up a whole DOORS module, when you select to import (the excel file in a csv format), you can choose to update or create.
If you pick update, it will ask for the column with unique identifiers (usually, the object IDs column) and for the objects that doesn't have a number, they will be created, updating the ones that do have an ID, but (as you state in the question) the new ones will be added at the bottom.
Now, we are only using the ID attribute of the objects, which makes them unique even if is moved, deleted or flushed, but for the meaning of sorting, that attribute is meaningless, because if you copy an object (from the same module or from another) the ID updates to the next available according to the ones in the module.
The attribute that tells DOORS how to structure and sort the objects, is actually the Object Number
"... hierarchical ..." is the keyword here. That attribute tells DOORS the order of the objects and which is parent/children of which.
Now, I don't really remember if that attribute can be modified in the csv, but there are two DXL scripts that combined, enable that while importing:
\IBM\Rational\DOORS\X.Y\lib\dxl\example\oslc\ hierarchy.dxl
\IBM\Rational\DOORS\X.Y\lib\dxl\standard\import\ commas.dxl
Unfortunatelly, I couldn't find the combined script, but I know it uses those 2 (some time ago I was making the DXL to do almost the same as you want, but someone else at my work managed to do it first and with time, it was no longer necessary)
Here is the reference manual (image is from page 402/1006)
And this page has some good scripts, too.
I hope my answer helps you to build that script (or find some coworkers that do it before you do, hehe)
I want to create a traceability matrix in a new module that shows the object ID & text at the top level, then in columns moving to the right the object ID & text for the source of the first in-link, and then it's in-links to the right, etc. If there is more than one in-link, the next source object will be shown on the next line (new object), and the higher level object ID & text just repeated in the columns to the left. Basically, it is the recursive trace analysis layout dxl, but I want to spread out the information over separate columns.
My question is related to the best practices for approach. Is it best to create a new module and write several dxl layout scripts for each column, pulling info from all of the various modules, and then later converting it to text (so it isn't too heavy)? Or is it necessary (or easier) to actually create dxl attributes within each requirements module, and then pull information from there into my RTM module?
I'm likely over-complicating it, but any tips would be appreciated!
Well, one of our assets contains something that looks like your approach:
script creates new modules that only contains trace information, a "report" module, which does not contain any link to the original "data" modules
there are some 2 or three columns for each Req Level (high level reqs at the left, low level reqs at the right)
the advantage of this approach is that one can easily use standard DOORS filtering mechanisms to find "holes" in the matrix (requirements which have not been implemented, design elements without requirement etc.). plus, as every report run creates a new report module with the date/time in its name, project progress can be made visible over time, reports to excels might be made.
On the other hand the implementation took several weeks. So, I don't know if this approach would be feasible for you.
I am wanting to show a list of all users for a particular app in holochain to enable an active user to make an agreement with someone. What is a best practice for getting a list of all users given the linking nature of the data flow?
Would it make sense to create a central agent that links to all the users to get access to the full user list? Is there a way that seems better?
Link from the DNA Hash (not recommended; read about anchors below)
Each user could link from the DNA hash to themselves in the genesis() function -- the DNA hash is the one hash on the DHT that everyone knows. Then all you need to do is getLinks(App.DNA.Hash, "user") to get them all. (watch out, it could get to be a huge list. I also feel bad for the poor nodes who are in the neighborhood of the DNA hash... that's a lot of metadata to store.
Doing this in Genesis
This can be done in the genesis function. I'll do it in old holochain-proto language, if you don't mind:
function genesis() {
commit({ Links: [ { Base: App.DNA.Hash, Link: App.Key.Hash, Tag: "registered_user" } ] };
}
That will create a sort of 'registered agent' thing for each new person who joins.
The problem with this approach
it's a bit of an antipattern, because a redundant copy of the DNA lives in the DHT as well, and the poor souls whose nodes are in the DHT hash neighbourhood of the DNA will have a higher load than others. Right now I'd recommend anchors instead. Anchors are nothing but a pattern that consists of a string entry + a link. So you would create an anchor whose content is "registered_users", and link from that anchor to any agent who comes on board. Still creates a hotspot for those who hold the anchor entry, but it's expected that your app will have a few anchors like this, and at least they don't have to all hang off the one DNA hash.
Linking with Anchors
The anchors mixin (currently compatible with hc-proto only) features an idempotent function to create the anchor, so each user could safely call anchor() without re-creating an existing anchor.
I have a field "taxonomy" and I would like to pass it to Omniture. This Taxonomy field can have multiple values and I would like to calculate the count for each of the taxonomy separately. Let me explain my question with an example:
Item can be associated with multiple taxonomy. Letz say we are talking about an item called "Item1". This item can be associated with taxonomy "Tx1","Tx2","Tx3".
So the js code will be like,
s.prop1 = "Item1"
s.prop2 = "Tx1, Tx2, Tx3"
I was expecting omniture to store individual buckets/counters for "Tx1" "Tx2" and "Tx3". But Omniture created one bucket for "Tx1, Tx2, Tx3". I hope there is a way to treat them separately. Ideally I would not like to pass the taxonomies separately in separate prop variables.
I would appreciate if someone can point me in the right direction.
Thanks,
Rag
Actually Omniture does support list-style props, aptly called a list prop. You have to talk to Client Care to enable it for your prop, and you will need to specify a delimiter to use (like the comma). Then you would populate it exactly as you are doing, except without the space between the comma and value. ("a,b,c" not "a, b, c").
An alternative is the list eVar as Racheet mentioned. The difference is that a list prop sends in values and each value is within a prop variable scope, vs. the list eVar values are recorded with an eVar scope.
If you decide to do it w/ a list eVar instead of list prop, read up on how Omniture handles the allocation for them..there are some implications to consider with them only being able to be set to first or last allocation...
Omniture does have the functionality you're looking for from version 15 onwards. Unfortunately it won't do it in a prop. You need to use a slightly different variable type. The variable you're looking for is a list eVar.
Every implementation has three of these available:
s.list1
s.list2
s.list3
Here's the blog post where Omniture introduced them.
You can also find information on them in Knowledge Base article 10549 from inside the Adobe Marketing Cloud interface.
Is it possible to translate the display name of choice list items defined for LightSwitch entity properties?
I would like to be able to show different users translated display names in their language when they are viewing the SAME record, and also show translated names in the autocomplete combo box when they are editing a record.
Not really, no. The values are stored in the LSML file & aren't able to be modified at runtime. If you need to translate the values, then you'll need to use a lookup table (possibly by using a custom RIA service) instead of a Choice List.
The advantage of a Choice List is that it's very quick & easy to set one up.
The down side of a Choice List is the lack of flexibility, or even reusability (you have to define the values for the list every time you want to use it somewhere).