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

Regarding iwglobal group

curiousmaverick

Background: We have a legacy system to maintain where log files generated from workflow related perl scripts have their group set as iwglobal. Now as we add new users to TeamSite, workflow run by these users get to a hung state. These users are not members of iwglobal. I tried with a higher privilege account who is a member of iwglobal, and workflows then run fine.

Questions:
1. Are non OS TeamSite users by default get added to iwglobal?
2. If not, do we have to add the user to this group manually, each time we add an user to TeamSite?
3. Finally should the log files be set with their group as iwglobal, at first place?

Find more posts tagged with

Comments

Adam Stoller

Background: We have a legacy system to maintain where log files generated from workflow related perl scripts have their group set as iwglobal. Now as we add new users to TeamSite, workflow run by these users get to a hung state. These users are not members of iwglobal. I tried with a higher privilege account who is a member of iwglobal, and workflows then run fine.

Questions:
1. Are non OS TeamSite users by default get added to iwglobal?
2. If not, do we have to add the user to this group manually, each time we add an user to TeamSite?
3. Finally should the log files be set with their group as iwglobal, at first place?

You should not muck with iwglobal.
The iwglobal group is the way in which TeamSite maps TeamSite Groups to an OS Group that the hosting server can grok.

I.e. - If I have three TeamSite Groups:

and I associate one of those groups with a particular file or directory within a branch (it doesn't matter which group) - if I go through the file system interface (Unix shell, Windows Cmd) and look at the group-ownership of that file or directory - it will say "iwglobal".TeamSite (or rather, the Interwoven File System) knows how to interpret the distinct TeamSite Group information. The OS does not.If you are creating files on the local disk (outside of a TeamSite branch) you should not be using TeamSite groups (they have no meaning outside he context of a branch) - nor should you be using "iwglobal" - as that should only be used by the TeamSite application itself.What you need to do is make sure your log files are world-writable, and generally within a world-writable directory.The way you do that is OS-dependent.

curiousmaverick

Thanks for the detailed response Ghoti.
On some further invetigation I found that some old TS users are members of iwglobal group (users existing before upgradation to 7.x). So did 6.x versions add the users to iwglobal which current version doesn't. Or how an user perhaps get added to iwglobal, as I've found that they were never used to be added to the group during 6.x version of the application.

Rick Poulin

You missed Adam's point. Your operating system cannot ever properly understand the iwglobal group because it means different things in different places. Whatever membership you're seeing at any given time is probably some OS-cached representation of what Iwov told it at one time. For all practical purposes, pretend that iwglobal doesn't exist. Find another group to use and save yourself needless head scratching.

curiousmaverick

I checked in the codebase, and found that in the logger perl script, group is getting set as "iwglobal" for log files.

While I fully understand and agree to what both of you have said so far, I'm still trying to know what could've been the possible reason for setting the group as "iwglobal" in legacy code.

A coding mistake perhaps? Would be great to hear your thoughts on this one.

Rick Poulin

What legacy code is that? If it's your own organization's custom code, then someone could have mistakenly assumed the iwglobal group was a 'normal' group and just went along with it. If it's legacy IWOV code, I'd only guess that the implementation of iwglobal has changed behind the scenes over the years, what with the non-OS users stuff a while back, and the complete role-reversal (pun intended!) in v6.x. If you're looking at some ancient perl file from v5.x, it's likely that at that time the group worked differently.

Adam Stoller

What legacy code is that? If it's your own organization's custom code, then someone could have mistakenly assumed the iwglobal group was a 'normal' group and just went along with it. If it's legacy IWOV code, I'd only guess that the implementation of iwglobal has changed behind the scenes over the years, what with the non-OS users stuff a while back, and the complete role-reversal (pun intended!) in v6.x. If you're looking at some ancient perl file from v5.x, it's likely that at that time the group worked differently.

If memory serves correctly, TeamSite Groups were introduced in 6.5 - and thus there would not have been an 'iwglobal' group before that unless someone at the customer site just happened to come up with that name before Interwoven did (possible, but highly unlikely)

I'd assume the "legacy code" being referred to is the organization's and not [HP [Authonomy]] Interwoven's - and it was probably a mistake that happened to work and now it's not - and it would be better to fix the code to something that should truly work rather than wasting a lot of time trying to figure out how to make a mistake keep working (IMO).

curiousmaverick

Thanks Ghoti for your response. And you are right, it's orgnnization's legacy code and not Iwov's.
I've suggested what you have recommended.

Thanks again.