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; } } }

Change Workarea Owner (TS 6.5) ?

homesick123

Please tell how to change the workarea owner .I am using windows 2000 server.
I think iwchgrp can only change the group having access to the wrkarea. Can iwchgrp be used to change the owner?
Can a group be marked in the workarea owner field ,while creating a workarea?
How to give multiple groups access to workarea through iwchgrp?

Find more posts tagged with

Comments

Nicholas

what version of TS you are using? and OS?

Nicholas

sorry, you mentioned TS version detail in your subject line.

Well. there is no direct way to change the workarea owner, if you want so you can create a new workarea, copy the files, remove older one and rename it.

Thanks Nicholas

kaalraa

Please tell how to change the workarea owner .I am using windows 2000 server.

You can not change the owner of a workarea... you need to create a new workarea with a new owner.

Can a group be marked in the workarea owner field ,while creating a workarea?

Only a single user can be specified as the owner, however a group can be assigned to a workarea for access.

How to give multiple groups access to workarea through iwchgrp?

Can not give multiple group names, but you can use TS groups to create a new group which has other OS groups as members. While creating the workarea provide that TS group name as accessible group. Read on more for tsgroups.xml.

homesick123

sorry, you mentioned TS version detail in your subject line.

Well. there is no direct way to change the workarea owner, if you want so you can create a new workarea, copy the files, remove older one and rename it.

Thanks Nicholas

What if i use submit.cfg and Setaccess as Owner to the New_Owner? How will that be useful ?

homesick123

What if i use submit.cfg and Setaccess as Owner to the New_Owner? How will that be useful ?

Iam sorry ,i meant Owner (not use Setaccess ) !

kaalraa

Iam sorry ,i meant Owner (not use Setaccess ) !

Submit.cfg changes the permission over the files to be submitted. It does not change your owner over the workarea.

Moreover it is a global config file which works on as per the branches and workarea defined within submit.cfg.

homesick123

You can not change the owner of a workarea... you need to create a new workarea with a new owner.
Only a single user can be specified as the owner, however a group can be assigned to a workarea for access.

Can not give multiple group names, but you can use TS groups to create a new group which has other OS groups as members. While creating the workarea provide that TS group name as accessible group. Read on more for tsgroups.xml.

Can i use Owner action of Submit.cfg?

kaalraa

Can i use Owner action of Submit.cfg?

Owner action of submit.cfg changes the owner of the files and directories being submitted.

Adam Stoller

What if i use submit.cfg and Setaccess as Owner to the New_Owner? How will that be useful ?

That will change the owner of any new-or-modified file and any new directory within the workarea - when the files and directories are submitted to staging - but it will not change the owner of the workarea.

If the issue is with an 'owner' who is no longer a valid TS user - you may want to look at the documentation on the CLT iwidmap - otherwise, creating a new workarea to replace the old one is really the best way (you can change the owner at the file system level, but that doesn't always reflect back correctly within TeamSite)

waikong

That will change the owner of any new-or-modified file and any new directory within the workarea - when the files and directories are submitted to staging - but it will not change the owner of the workarea.

If the issue is with an 'owner' who is no longer a valid TS user - you may want to look at the documentation on the CLT iwidmap - otherwise, creating a new workarea to replace the old one is really the best way (you can change the owner at the file system level, but that doesn't always reflect back correctly within TeamSite)

Hi Ghoti,

Just wonder if we create a new workarea to replace the old one (use back the same workarea name), will the version of file be lost?

kaalraa

What is the basic requirement, for assigning a particular user to owner of workarea? If that person leaves out, then again you would be in same situation.

My suggestion would be to make owner ... as tsadmin and allow access to a group in which al users should be added/removed as per requirement.

As per your query, the same name of workarea picks up the version for last deleted workarea of same name.

moonkhanna

I ran into a similar scenario a month or so ago. As kaalra states, I think, assigning tsadmin as workarea owner would be the best approach to your scenario.

You can change sharing group for your workarea using the iwchgrp command on the workarea. I do not remember the syntax now but just try that on your server and you should be able to change the sharing group successfully.

Adam Stoller

Hi Ghoti,

Just wonder if we create a new workarea to replace the old one (use back the same workarea name), will the version of file be lost?

As per your query, the same name of workarea picks up the version for last deleted workarea of same name.

I do not believe that answer is correct.

If you delete workarea X (or rename workarea X to workarea Y) and then create a new workarea X, that new workarea has no connection to the old workarea X other than that they both are on the same branch and thus reference the same staging area, etc.

When you create a workarea, you will be asked for an edition to use as its base for initialization, by default I believe you will be provided the name of the most recent edition on that branch. The new workarea will then get all the versions of the files that are associated with that edition. Generally, the first thing you should do after creating the new workarea is run Get Latest - which will then make sure that you have the latest version of each file in your workarea.

Any files that were deleted-but-not-submitted in the old workarea X will not be marked as deleted in the new workarea X.

Any files that were new-and-not-submitted in the old workarea X will not be present in the new workarea X

kaalraa

If you delete workarea X (or rename workarea X to workarea Y) and then create a new workarea X, that new workarea has no connection to the old workarea X other than that they both are on the same branch and thus reference the same staging area, etc.

Adam,

I know you are absolutely right, but what about the phrase you have written yourself. As IMO, the workarea to be created is within the same branch.

Correct me if i am wrong, in anyways.

waikong

my scenario is a little bit tricky...

we have 12 DCT, and 5 division, and we creates the workarea accodging to the matrix below:

+-----------------------+------------------------------+
|.......................|Ret...|Net..|CCM..|ENT..|PTNR.|
+-----------------------+------------------------------+
|cat1/crm...............|......|..o..|.....|..o..|.....|
|cat1/lnr...............|...o..|.....|.....|.....|.....|
|cat1/market_intellince.|...o..|..o..|.....|.....|.....|
|cat1/products..........|...o..|.....|..o..|.....|.....|
|cat1/promotions........|...o..|.....|..o..|.....|.....|
|cat1/sales.............|......|..o..|..o..|.....|.....|
|cat1/services..........|......|.....|.....|..o..|.....|
|cat1/training..........|......|.....|.....|..o..|.....|
+-----------------------+------------------------------+
|cat2/about.............|......|.....|.....|.....|..o..|
|cat2/products..........|......|.....|.....|.....|..o..|
|cat2/promotions........|......|.....|.....|.....|..o..|
|cat2/training..........|......|.....|.....|.....|..o..|
+-----------------------+------------------------------+

*Edited(Across the vertical line is DCT, and across the horizontal line is division)

since we are not having all the DCT, so they will be selectivly copy to the workarea.

my problem is when a workarea owner left, we create a new workarea we can't select an edition, because those editions contain. all DCT. any idea how to change workarea owner without removing the exisging one?....

Environment:
TeamSite 6.5 SP2 Windows Server 2003

MAK

Hi,

May be not the best option but you can give this a try.
Change the owner at the file system level.

waikong

Hi,

May be not the best option but you can give this a try.
Change the owner at the file system level.

Do you mean changing the owner of the workarea folder? I not sure will that really cange the workarea owner...

Anyway, will that solve the locking issue? eg. some files been locked by the current workarea owner, and some pending workflow is still in his bucket...

MAK

Hi,

Do you mean changing the owner of the workarea folder? I not sure will that really cange the workarea owner...

If you change the owner of the folder, it will change the workarea owner. I m sure this works on Win2K3 and should work on UNIX as well.
BUT i still feel this is not the recommended way.

Anyway, will that solve the locking issue? eg. some files been locked by the current workarea owner, and some pending workflow is still in his bucket...

Yes, you are correct that there are other issues like files, jobs/tasks, locks owned by the old owner and should be taken care using idmap, etc in any case.

Adam Stoller

Do you mean changing the owner of the workarea folder? I not sure will that really cange the workarea owner...

Anyway, will that solve the locking issue? eg. some files been locked by the current workarea owner, and some pending workflow is still in his bucket...

Try using iwidmap to map the userid of the person who left to someone else who's there - that should change the ownership of all files, directories, and (I believe) tasks.

Note also - trying to have different files in different workareas on the same branch is not a recommended practice - it will either be difficult to maintain or it required even more non-standard practices.

Adam Stoller

Adam,
If you delete workarea X (or rename workarea X to workarea Y) and then create a new workarea X, that new workarea has no connection to the old workarea X other than that they both are on the same branch and thus reference the same staging area, etc.
I know you are absolutely right, but what about the phrase you have written yourself. As IMO, the workarea to be created is within the same branch.

Correct me if i am wrong, in anyways.

I'm not sure what you're trying to say here. Your original comment was that a newly created workarea with the same name of an old deleted workarea would somehow inherit the modifications the used to exist in that old deleted workarea.

My statement was that you were wrong and that the only association the two workareas have in common are their names and the branch they are associated with - there is no historical relationship between the two workareas.

waikong

Try using iwidmap to map the userid of the person who left to someone else who's there - that should change the ownership of all files, directories, and (I believe) tasks.

Note also - trying to have different files in different workareas on the same branch is not a recommended practice - it will either be difficult to maintain or it required even more non-standard practices.

Noted, I will try on using iwidmap, that will also change the ownership of the workarea owner, correct?

I understand the difficulty of maintaining different files in different workarea, and therefore I had a custom batch files will call a series of CLT to perform a selective get latest.

Thanks for your advise.

Adam Stoller

Noted, I will try on using iwidmap, that will also change the ownership of the workarea owner, correct?

I'm assuming that the "old" user is no longer a member of the system - right?
Yes - this will change everything owned by the "old" user (within the TeamSite backing store) to be owned by the "new" user.

I understand the difficulty of maintaining different files in different workarea, and therefore I had a custom batch files will call a series of CLT to perform a selective get latest.

The problem with a "selective Get Latest" is that it can only be selective based upon what it knows - as you add more files and directories, you will have to continually update the "knowledge" of these scripts -- you're generally better off using a more detailed submit.cfg file and setting up the ACLs on files and directories correctly so that users in different workareas simply have access to different files and/or directories - but the workareas themselves are complete.

cute_guy

I'm assuming that the "old" user is no longer a member of the system - right?
Yes - this will change everything owned by the "old" user (within the TeamSite backing store) to be owned by the "new" user.The problem with a "selective Get Latest" is that it can only be selective based upon what it knows - as you add more files and directories, you will have to continually update the "knowledge" of these scripts -- you're generally better off using a more detailed submit.cfg file and setting up the ACLs on files and directories correctly so that users in different workareas simply have access to different files and/or directories - but the workareas themselves are complete.

I have similar kind of problem

I have used chown command to change the ownership of myworkarea & branch.
Since the branch and workarea are treated as directories in solaris it got changed to new owner, but the WORKAREA,STAGING,EDITION did not get changed to the new owner, it throws an error read only file system.

I did not use iwidmap, because the old owner exists in system i cannot replace the old owner user id with new owner user id.

How can we change the ownership of WORKAREA,STAGING,EDITION to new owner.

I believe if the ownership is not changed to the new owner, the new owner cannot delete editions in the EDITION area right?
Will there be any other problems

------------------
TS 6.5 sp3, Solaris 8

Adam Stoller

I have similar kind of problem

I have used chown command to change the ownership of myworkarea & branch.
Since the branch and workarea are treated as directories in solaris it got changed to new owner, but the WORKAREA,STAGING,EDITION did not get changed to the new owner, it throws an error read only file system.

I did not use iwidmap, because the old owner exists in system i cannot replace the old owner user id with new owner user id.

How can we change the ownership of WORKAREA,STAGING,EDITION to new owner.

I believe if the ownership is not changed to the new owner, the new owner cannot delete editions in the EDITION area right?
Will there be any other problems

------------------
TS 6.5 sp3, Solaris 8

Those "directories" are "special" and the rights you see on them may or may not be "accurate" (sorry about all the quotes) - as the access through this is managed completely by Interwoven's virtual file manager and not the OS. Once you get within those directories, then you start dealing with both the Interwoven virtual file manager and the OS.