How to set 3 different types of acces in a w/a?

Hi,
we have TS6.1 on Solaris 8.
Like most, we generally allow access to a branch/workarea by setting 1 group-for-sharing for the branch/workarea and setting the group-write bit on for all dirs/files in the branch, thus giving access to all users who are a member of that group. However we need to define 3 different types of access within certain workareas as follow:
1. read-only (easy, I'll just take away the group write bit for these files/dirs)
2. restricted - able to be edited by higher-level users (say Admins & Editors) but not by others (say authors)
3. editable by all users of the branch - that is naturally enabled if group-write on.

So the problem is no 2. How could we differentiate between Authors and other roles in terms of which files they can edit? (or any other way, but roles-based seemed logical as it is supposed to be hierarchical).

BTW, along with taking away submit-direct for authors, I was looking at the concept of disabling the "edit" button for Authors (but not editdcr), BUT there appears to be a bug where the Edit > Edit choice and the Edit button on the toolbar are disabled, but the Edit button for the file itself (with "Properties") is NOT disabled, which makes that facility useless. Anyone know about that?

Anyone have any ideas?

Find more posts tagged with

Comments

Migrateduser

Solution I: Edti workflow that apply's the rules for editing content in branch/workarea.

Solution II: A post response filter that apply's the rules for editng content in the branch/workarea. This requires TeamSite UI customization.

Adam Stoller

Hi,
we have TS6.1 on Solaris 8.
Like most, we generally allow access to a branch/workarea by setting 1 group-for-sharing for the branch/workarea and setting the group-write bit on for all dirs/files in the branch, thus giving access to all users who are a member of that group. However we need to define 3 different types of access within certain workareas as follow:
1. read-only (easy, I'll just take away the group write bit for these files/dirs)
2. restricted - able to be edited by higher-level users (say Admins & Editors) but not by others (say authors)
3. editable by all users of the branch - that is naturally enabled if group-write on.

So the problem is no 2. How could we differentiate between Authors and other roles in terms of which files they can edit? (or any other way, but roles-based seemed logical as it is supposed to be hierarchical).

BTW, along with taking away submit-direct for authors, I was looking at the concept of disabling the "edit" button for Authors (but not editdcr), BUT there appears to be a bug where the Edit > Edit choice and the Edit button on the toolbar are disabled, but the Edit button for the file itself (with "Properties") is NOT disabled, which makes that facility useless. Anyone know about that?

Anyone have any ideas?

Firstly, you should make sure you configure your submit.cfg correctly to set and preserve the access rights you want.

Secondly, are you sure you need to limit the accessibility of those files by 'role' - rather than by 'user'? If someone has the ability to login with both Author and Admin roles - should they not be able to edit those files when logged in as Author, but only when logged in as Admin? I'd consider just using a different group for the access rights on those files and make sure that the people you want to allow to edit those files are in that group, and the people you don't want to allow to edit them aren't.

Lastly - each of the menu items, links, etc. in the UI are controlled by different entries - you need to make sure you find the piece that controls the Edit option on the Properties menu (if you cannot, consider opening a case with Support - if it turns out not to be possible, open a FR for it).

Otherwise - you can do something like what batasari suggested.

Rainbow_Warrior

Thanks Ghoti.
Couple of points regarding your answer:

1. I accept that anyone with more than 1 role can log in as their highest role in any branch they have access to. I'm planning to have each user with just 1 role - e.g. authors are only authors. Also we are running into problems with users exceeding their 16 group membership, so would prefer not having extra groups under the workarea (otherwise, yes, that would be the easiest solution, but not if we have to do it for every branch). Forgot to mention these in the first email.

2. That's why I'm looking at trying to differentiate by role. As it seems that the requirement of "low level" users is basically to edit DCRs, whereas higher level users can change jsps, tpls etc (in different areas e.g. data v presentation dirs), I thought the idea of disabling the Edit button but allowing the EditDCR button for authors, together with the inability to submit-direct might be a reasonable solution.

3. I was hoping to lessen our dependence on the submit.cfg I have inherited. Ours is huge, and sets exhaustive permissions in each branch (755,744,775,757) depending on the area and the type of file. To me it is way over the top and unnecessary (775 should simply suffice for most), and I suspect takes rather too much processing - every time a submit is performed it gets spat out into iwtrace (and it's 15000 lines long!) and any missing groups also spit out recurring error messages, giving us another admin job. Also, my understanding of submit.cfg's role is that it sets file/dir owner, group and permissions in the workarea PRIOR to submitting (those permissions don't apply in Staging, or when deployed, just the w/a). That means it is setting permissions AFTER the fact, which is logically wrong. Why would we use submit.cfg in preference to setting correct unix permissions in the workarea in the first place, and if they do change for certain directories (which of course they shouldn't!), employ something like a setgid to hold them?

So I guess my follow-up questions would be:
- Would a 15000 line submit.cfg significantly affect processing resources?
- Why would we use submit.cfg in preference to setting correct unix permissions in the workarea in the first place?

Thanks in advance for any answers.

Adam Stoller

Thanks Ghoti.
Couple of points regarding your answer:

1. I accept that anyone with more than 1 role can log in as their highest role in any branch they have access to. I'm planning to have each user with just 1 role - e.g. authors are only authors. Also we are running into problems with users exceeding their 16 group membership, so would prefer not having extra groups under the workarea (otherwise, yes, that would be the easiest solution, but not if we have to do it for every branch). Forgot to mention these in the first email.

2. That's why I'm looking at trying to differentiate by role. As it seems that the requirement of "low level" users is basically to edit DCRs, whereas higher level users can change jsps, tpls etc (in different areas e.g. data v presentation dirs), I thought the idea of disabling the Edit button but allowing the EditDCR button for authors, together with the inability to submit-direct might be a reasonable solution.

3. I was hoping to lessen our dependence on the submit.cfg I have inherited. Ours is huge, and sets exhaustive permissions in each branch (755,744,775,757) depending on the area and the type of file. To me it is way over the top and unnecessary (775 should simply suffice for most), and I suspect takes rather too much processing - every time a submit is performed it gets spat out into iwtrace (and it's 15000 lines long!) and any missing groups also spit out recurring error messages, giving us another admin job. Also, my understanding of submit.cfg's role is that it sets file/dir owner, group and permissions in the workarea PRIOR to submitting (those permissions don't apply in Staging, or when deployed, just the w/a). That means it is setting permissions AFTER the fact, which is logically wrong. Why would we use submit.cfg in preference to setting correct unix permissions in the workarea in the first place, and if they do change for certain directories (which of course they shouldn't!), employ something like a setgid to hold them?

So I guess my follow-up questions would be:
- Would a 15000 line submit.cfg significantly affect processing resources?
- Why would we use submit.cfg in preference to setting correct unix permissions in the workarea in the first place?

Thanks in advance for any answers.

For issue number 1 - I suggest looking into upgrading to at least 6.5SP2 - though 6.7 or 6.7.1 (when it comes out) might be a better choice - as those versions allow you to create TeamSite Groups - which do not suffer from the 16-group limitation imposed by NFS.

# 2 is certainly a reasonable approach - and it sounds like you might have that mostly working - I again suggest that you wade through the UICG and/or all the reference files in IWHOME/local/config/lib/content_center to see if you can find the settings you need to remove/control the one piece that you indicated wasn't working for you.

With regard to the submit.cfg - it's certainly possible that there's some performance issues - I believe it only gets dumped into the log file if an error is noticed (but I could be wrong there) - that's certainly a large file, and you might look for ways to better generalize the regex's to reduce it's size. Using chmod g +s on the directories in question, is certainaly a means of reducing the need for the submit.cfg, but if you need distinct permissions on different files within the same directory - you really need to use the submit.cfg. It's not entirely post-operative, I believe it sets the permissions in the workarea just-prior to performing the actual submit - so the files that appear in the staging area should have the same permissions as those that appear in the workarea (though I do recall that various versions of TeamSite have not accurately reflected this in the past - I haven't investigated this at any length recently).