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

Creating workarea per user

milind

Hi,
I wanted to that is it a good idea to create workarea for each user ?
will it make any effect on the speed ?
Users should not be able to oevrwrite content of another user.
We may have users @10 and each workarea will have @1500 dcrs ...

Please give ur comments.

Find more posts tagged with

Comments

gzevin

eventually it will affect the server performance. however, if you spec'ed out your server Ok, it should be fine.

another thing is the branching structure. YOU have to realise as to why you want one workarea per user. IMO, this does not make sense, in some cases there I can see some admin/development workarea for a single user, but still.... think twice

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Migrateduser

Hi milind.

As per the IW suggestions, you need 1 CPU with at least 3.0 GHz Processing speed and 2 GB RAM. The spped varies on diff factors :-

CPU and RAM recommendations for a system running the TeamSite server are based on the activity level of users who are concurrently using TeamSite, the total number of licensed TeamSite users, and the size of the Content Store.

CPU and RAM recommendations for the system running the Interwoven Search server are based on the type of content being searched (such as documents, data records, or extended attributes), the frequency of query operations, and the required query response time.

CPU and RAM recommendations also are based on whether the TeamSite and Search servers run on the same system or separate systems.

~Rishi Gupta

milind

Thanks Greg and Rishi for ur replies

Regards
Milind

Adam Stoller

One additional item - at least until 6.7 - do not make Authors [users who are *only* allowed to log in with the Author role] owners of workareas. Doing so will break many OOTB workflows, and will make it difficult to correctly write your own. The reason for this is that all versions of TeamSite (up to and including 6.5) will not allows Authors to submit files to the staging area - and most workflows tend to include a submittask which is either owned by the user who initiated the job or by the area's owner (usually the latter).

So - even if you create a separate workarea for Tom, ****, and Harry - if they can only login as Author - the workareas should be *owned* by someone who has at-least Editor access - and then it can be *shared* with a group that contains the actual user of the workarea.

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

gzevin

very good point, actually.

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

shanon

In reply to:

So - even if you create a separate workarea for Tom, ****, and Harry - if they can only login as Author - the workareas should be *owned* by someone who has at-least Editor access - and then it can be *shared* with a group that contains the actual user of the workarea.

I would go so far as saying that it's a best practice to make workarea owner = branch admin and have the group for sharing set as necessary.

for your requirement however, that users cannot mess with other users' files... not sure that you want to do this all in the same branch b/c as soon as a "get latest" is performed on any workarea, that workarea will contain everything from the STAGING area (including all of the files that were submitted from the other workareas). after this operation is performed, the user will (99% sure here) be able to edit/modify these files and perform the same operations possible on files they originally created.

remember, workareas are just a copy of the STAGING area +/- any local changes. they're certainly not mutually exclusive. branches, on the other hand, are.

a single branch does have some benefits though... so maybe disable the "Get Latest" command?

some options...

- this will be easiest: check if you can make the menu options based on role. if so, just make the "Get Latest" command for Masters and Admins only. not sure if this is possible w 6.5 but will be w/ 6.7.

- otherwise, disable it... i don't think that you can do this per-workarea... it's per-server right now ( maybe a good feature request for next-gen UITK: vpath-based menu fx). don't worry too much here: just b/c you disable it, doesn't mean you can't use it. remember, you can (a) still run the CLT and (b) still use CSSDK and (c) write a custom-menu item available just to masters/admins that does it (if you must have it).

i'm sure there are other ways, anyone?

-shanon.
--------------------------
Sr. Solutions Engineer
shanon at interwoven dot com

awizardly

Alot of your branching and workarea strategy depends on your content organization and security needs. It's hard to say which is necessarily better without a little more information.

In the case of Get Latest, It's hard to understand why you would want to remove the get latest command from the UI.
Get Latest is an essential part of working in multiple workareas, it's like doing a cvs update to make sure that you have the most recent checkout/version of everything in your workarea. Very rarely can a single user work with only a portion of a site and not "see" any other users work. Websites don't just work with a portion of the content.
I can see some concerns about security, but if there is really that much concern you can obviously look at different branches for content responsibility and the use of iwproxy to stitch them together into a virtualizable site.
If your concern around Get Latest picking up files from other users workareas is that an end user can then edit files that they haven't created?
I would suggest that you use submit.cfg to force permissions on files so that people can't "edit" files that you don't want them to.
This is obviously easier to do if you have a clear definition of what files to which different users should have access.

I guess I would like to understand in what situation would it be useful to remove the get latest functionality, and go to the trouble of making it useable only by admins and masters.

Lee
Organic Inc
http://www.organic.com

shanon

i agree... i really don't think it's a good idea... just an option.

after thinking a bit more, i believe that you can accomplish this ( and maybe this is simplier ) with a single workarea and OS-permissions.

put all the users in a workarea group: wa-group
make the workarea shared by the workarea group.

add harry to a new group: harry-group
repeat for tom & **** ...

you have three dirs in the workarea

/harry # harry-group has access here.
/tom # tom-group has access here
/**** # ****-group has a access here

use windows explorer to change the permissions on the Y: drive. remove wa-group's access entirely. just leave the TeamSite Web Daemon and harry-group and optionally Administrators.

hth.

-shanon

milind

Hi All,
Thanks for your replies......
I have got better understanding of uses of workareas.
Any more suggestions and openions are welocme.

Regards
Milind

g_sal

Please correct me if I'm wrong...

I've been experimenting with permissions and branch structures. Running T6.5 on Win2k3 and noticed a couple of things:

1. Disallowing a user to delete a folder in the OS will not protect the folder in TeamSite. The user will be able to delete the folder.
2. Disallowing write access in the OS will not protect your data either. Teamsite will let a user download, edit, then upload the changes. At this point TeamSite tells the user it has no permissions to edit the file, but the file is marked as deleted.
3. Restricting read access will prevent users from accessing folders in TeamSite.

One would then assume that dividing your project in different sub-branches will provide more access control. Problem is these sub-branches will not share the same data types. If you want to use the same data types for your subbranches, you'll have to create your own workflow that will copy your templatedata files across the sub-branches. You can expect update anomalies when administrators forget to run the workflow. Another disadvantage is the limitations of the browse button in the DCT. You will not be able to point to files outside your workarea (some workarounds available on devnet apparently).

I'm inclined now to use one branch for a project/website and have one workarea despite the disappointing performance of OS permissions in TeamSite.

milind

Hii again ,
We are going to implement workflow in TeamSite6.1.
The requirement is as below in brief.
We have a groups of authors, editors and reviewers.
When a author creates the content he/she sends it to the editor group.
If required editor sends this content to one or more of Reviewer groups for review.
Review by editor and Reviewers are the group tasks.
we dont want to create workareas per group since there will be 7/8 groups and hence workareas.

To meet the requirements we are planning to have a master group, all other groups will be member of this group.
There will be only one workarea and the owner will be the master group.

Can you please let us know if this approach is fine or we should make any changes to it !!

Thanks in advance

Milind

gzevin

It's ultimately you who come up with the bracnhing/workea structure. If you think that one workarea is what you need and how to implement business rules for so many user group, that's fine. I myself can't see why 7/8 workareas is wrong.

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU