nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Properties of File in History

System

TeamSite 5.5.2 on W2K.

File->File Properties seems to be disabled for entries in View->History. Other than reverting, is there any way to determine what DCR was used to generate a previous version of a file? It looks like a user accidentally overwrite an existing file by generating from the wrong DCR.

Find more posts tagged with

Comments

Adam Stoller

Can you run iwextattr on the actulal version of the file from the command line on the TS Server?

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

You mean one of the hidden editions? iwextattr would work on the current version in STAGING/WORKAREA, but to get the old properties I would have to figure out which edition or revert, both of which seem ridiculous. In fact this whole problem is ridiculous. I think the CMS must enforce rules for generation (I did not architect this solution) - having this **** nilly manual business is a major expense and waste of time. Of course, with no best practices document from Interwoven on this subject, all new initiatives are likely to have the same problems. I just can't believe how serious this problem is and that it is not important to Interwoven. This is extremely frustrating (it is not just affecting one file), making the users want a "centralized" content management model which basically defeats the whole purpose of CMS.

Adam Stoller

My point is that just because they put in some restrictions via the GUI doesn't mean those restrictions are actually imposed by the system - just the GUI.

I'm not sure why File Properties is blocked from working on historical versions of files in the GUI - but iwextattr does NOT seem to have the same problem when run from the command line.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

How do you run iwextattr against a previous version, since only the current and next versions are in WORKAREA and STAGING? Are you running it against a file in an edition? I don't see a (5.5.2 documented) flag to pass a version identifier to iwextattr:

C:\temp>iwextattr -h
Usage: iwextattr [-s attr=value | -g attr | -d attr | -l] [-f] vpath
Set, get, or delete extended attributes of the file
or directory specified in the vpath.
The vpath is in the form:
[//server]/archive{[/branch]+}/{EDITION,WORKAREA}/dirpath
-h Print this message.
-v Print version string.
-s attr=value Set <attr> to <value>.
-g attr Get the value of <attr>.
-d attr Delete attribute <attr>.
-f Read/write attr value from stdin/stout for
-s and -g options.
-l List attributes and values.
-u UTF8 encode EA values on input, and decode on output.
If no option is specified, attributes are listed as with -l.

Migrateduser

I was similarly intrigued by this. Just for giggles, I tried it with an objid to see if perhaps that was an undocumented feature.

No joy in Mudville:

C:\Documents and Settings\V009272>iwextattr -l 0x000010084117bb02400006be
ERROR:02006: Error locating 0x000010084117bb02400006be

nipper

I think reverting is your only choice. I had thought that you should be able to get to that from Iwattrib
but I cannot find any way to do that.

It is very much of a hack, but revert, view restore seems lke a reasonable option

Andy

Adam Stoller

~ > iwrlog /default/main/TS_CODE/STAGING/modules/doe_deploy.pm | egrep "^(revision|last modified)"
revision /main/TS_CODE/5
last modified Thu May 6 08:09:38 2004 by fish in area #422
revision /main/TS_CODE/4
last modified Wed Apr 21 08:56:55 2004 by fish in area #401
revision /main/TS_CODE/3
last modified Tue Apr 20 11:46:21 2004 by fish in area #390
revision /main/TS_CODE/2
last modified Thu Jan 22 16:03:53 2004 by fish in area #2
revision /main/TS_CODE/1
last modified Thu Jan 22 16:03:53 2004 by fish in area Release1.3_SystemTest_Candidate_01So - if I want to look at the EAs on version 3 of this file, I would use the command:~ > iwextattr -l /default/main/TS_CODE/EDITION/#390/modules/doe_deploy.pmThere might be a "cleaner" way to do this, but I don't often need to do this so the occasional manual steps doesn't bother me.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

Gotcha.

That only works if the version you're after exists in an edition, though. If two changes to the file had been submitted between publishes, you might not have the version you were looking for.

nipper

>That only works if the version you're after exists in an edition, though. If two changes to the file had been submitted between publishes, you might not >have the version you were looking for.

If this is 552 + then it will work for the hidden editions & you are good to go.

Of course John is a MS guy, so he likes GUIs. & There he is SOL.....

Andy

Migrateduser

Thanks, I may try this when it comes up again but for today the user has decided to just remake the changes manually. Also, it would be nice if the user could be responsible for this type of activity (I absolutely hate getting involved in what I consider content issues) without having to teach command line syntax and give console access, but I've seen the light of NOT customizing the UI. It's funny, they bought this thing thinking it would give them audit and rollback, but without realizing the cost (I basically recommended the user just fix it by hand). There are other problems with the implementation here that really made the problem worse (regen runs daily, causing a new version, and UI limits view to some number of versions)...

Migrateduser

> Of course John is a MS guy, so he likes GUIs.

What? I'm a Unix fan (though I do feel that M$ OS are getting better - we'll see in 10 years). Actually, I used to prefer Commodore technology and coined the expression "Microsoft - if you're not explicitly against them, you're implicitly with them." But who has the R&D budget to push the technology envelope? I personally think .NET provides a better toolset than Java and I can't wait until Mono works, but let's not start another religious war...

As far as UIs, I personally hate the mouse and prefer the console, but as an architect/developer I don't like getting calls from users regarding existing disasters - I like to see new initiatives getting prioritized, designed and implemented. Supporting a poorly-architected TeamSite implementation can make that pretty challenging.

Edited by john on 08/31/04 02:53 PM (server time).

nipper

>> Of course John is a MS guy, so he likes GUIs.
>
>What? I'm a unix fan

My bad, I just assume everyone that dislikes Perl is "one of them"

Migrateduser

Oh Perl. You got me right on that one.