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

iw_ostream permissions control?

TommyWillB

For every HTML file I also crate a .JSON file osing a TPL iw_ostream:

(iw_ostream buffer='json' file_val="$output_json_file")(/iw_ostream)

Oddly, the permissions of the generated html file don't match the permissions of iw_owstream json file.

This is keeping other TeamSite users from re-generating this file.

Is there any way to make iw_ostream explicity set the unix user/group?
Is there any way to make iw_ostream explicity set the permissions to 777?

This is TS 6.7.2SP2 running on Solaris.

Find more posts tagged with

Comments

nipper

If the owner of the JSON file is the same as the user executing the TPL then you can explicitly set the permissions/owner/group (not, IMHO, the best approach). What user owns the JSON file ? What is the default umask for that user ?

First, are you using the submit.cfg file ? If it is properly set then you should not have many problems (only files changing before they were submitted).

Finally you can set the group sticky bit on the directory that holds the JSON files. That forces new files to inherit the group from the directory rather than from the user.

HTH

Andy

TommyWillB

> If the owner of the JSON file is the same as the user executing the TPL

The first time thru, the index.json doesn't exist...

...so, yes, it seems to be inheriting the unix permissions (owner + default-group) of the TeamSite user regenerating the index.html. (i.e. executing the TPL)

> submit.cfg ... properly set

I'm not sure how this has anything to do with submit.cfg, since this is only an issue of writing the file in the workarea... before it's submitted.

> Finally you can set the group sticky bit on the directory that holds the JSON files.
> That forces new files to inherit the group from the directory rather than from the user.

Okay, now that makes sense.

I'll ping our IT TeamSite Administrator to see if they'd let us do that.

nipper

> submit.cfg ... properly set
I'm not sure how this has anything to do with submit.cfg, since this is only an issue of writing the file in the workarea... before it's submitted.

You will also need to make certain the users umask is set properly (002) so that group write permissions will be set.

You are correct about it not affecting a new file being created. But it does affect the file being regenerated. I was not certain from your first post whether the error was on 1st creation or 33rd version of said file.