TM1 Forum

Hi all,
today I ran in an unexpected issue with PublishView.
I build a process to be used for a special group of users to publicate (private) views using PublishView.

Everything works fine for me (as an ADMIN). I can publish private views containing private subsets using PublishView(<Cube>, <View>, 1,1) (include Subsets =1 and overwrite =1). Even republishing a new private View with the same name and (changed) private subsets works if overwrite is set to 1.
With overwrite =0 i get the expected "aready exists" error...


Testfeedback from user:
First time PublishView works as expected if subsets are unknown. But if a public subset with the same Name already exists the process is terminated with error (yes: Overwrite is set to 1!) executing the normal rollback:
Fehler: Prolog Prozedurzeile (430): Das Subset "aktuelles Jahr" ist bereits in Dimension "<2>" vorhanden.
(Error: Prolog procedureline (430): The subset "aktuelles Jahr" already exists in dimension "<2>".)

Seems to me that the "overwride" option is not working as expected - but i did not find any hint concerning security issues (like "ADMIN-Permission required") , a bug or other possible traps ...
I looked for know issues and fixes regarding this - did not find anything.
Any ideas what can cause this error?

Holger

its a PA 2.0.9.1

The 4th argument of PublishView is not a blanket overwrite, it's "OverwriteExistingView" which will controls overwrite of the view only if it already exists. I wouldn't expect that to drive ability to overwrite a public subset if it exists already. I'm guessing you would rarely, if ever, want someone's private subset to overwrite a public subset. I've used python in the past to find private subsets in views to publish and resaving the subset as a private one with unique name and attaching to view before publishing.

ascheevel wrote: ↑Thu Jul 25, 2024 4:29 pm The 4th argument of PublishView is not a blanket overwrite, it's "OverwriteExistingView" which will controls overwrite of the view only if it already exists.

Good point.
I overlooked this because it was well working for me even with changed private subsest ... so maybe it only worked because "I" published the public subsets before?!

ascheevel wrote: ↑Thu Jul 25, 2024 4:29 pm I wouldn't expect that to drive ability to overwrite a public subset if it exists already. I'm guessing you would rarely, if ever, want someone's private subset to overwrite a public subset.

Sadly thats the request...

ascheevel wrote: ↑Thu Jul 25, 2024 4:29 pm I've used python in the past to find private subsets in views to publish and resaving the subset as a private one with unique name and attaching to view before publishing.

Let me check if i got your aproach:
1. you checked the private view for private subset (can you point out what is the indicator for private subset in view definition)
2. you checked if a public subset of that name already exists
3. you "genereated" a new subset (via copy in directory or via SubsetCreate?) (any suggestions for a "good" unique name acceptable for users aside from a timestamp?)
4. you use PublishView with OverwriteExistingView

If you make the user and ADMIN of the dim in question with the private subset are they then able to Publish the view? I know a TI executes as Admin, but perhaps there's a safety catch in the PublishView function preventing a subset overwrite if the user doesn't ADMIN access to the dim.

hju wrote: ↑Thu Jul 25, 2024 4:55 pm Let me check if i got your aproach:
1. you checked the private view for private subset (can you point out what is the indicator for private subset in view definition)
2. you checked if a public subset of that name already exists
3. you "genereated" a new subset (via copy in directory or via SubsetCreate?) (any suggestions for a "good" unique name acceptable for users aside from a timestamp?)
4. you use PublishView with OverwriteExistingView

Pretty much:
1. In python create two tm1 connection objects (first as myself, an admin called "tm1" and second impersonating the user in question called "tm2")
2. Gather private view definition using tm2 connection
3. iterate over all dims in view, if named subset is used, check if private subset exists by that name
4. if private subset exists, create a copy of that subset appending the userid as suffix for name and use the admin tm1 object to publish as public (the userid for suffix is usually easier with mode1, some other method might be needed for mode 5)
5. replace prior private subset in view definition with public one and then using the admin tm1 object create the view as public

ascheevel wrote: ↑Thu Jul 25, 2024 8:07 pm If you make the user and ADMIN of the dim in question with the private subset are they then able to Publish the view?

i tried that (general ADMIN), but no effect.
There is no DimensionSecurity in place!

ascheevel wrote: ↑Thu Jul 25, 2024 8:07 pm I know a TI executes as Admin, but perhaps there's a safety catch in the PublishView function preventing a subset overwrite if the user doesn't ADMIN access to the dim.

thought of somnething like that too, But I founf no proof so far.

ascheevel wrote: ↑Thu Jul 25, 2024 8:07 pm Pretty much:
1. In python create two tm1 connection objects (first as myself, an admin called "tm1" and second impersonating the user in question called "tm2")
2. Gather private view definition using tm2 connection
3. iterate over all dims in view, if named subset is used, check if private subset exists by that name
4. if private subset exists, create a copy of that subset appending the userid as suffix for name and use the admin tm1 object to publish as public (the userid for suffix is usually easier with mode1, some other method might be needed for mode 5)
5. replace prior private subset in view definition with public one and then using the admin tm1 object create the view as public

I am not familiar with python in TM1 context. But I got the point.
Will check some possible solution.

Was not aware that "OverrideExistingView" with additional "IncludeSubsets" option did not cover "OverrideTheIncludedSubsets"...

Holger, thanks for testing my questions on dim security and reporting back.

ascheevel wrote: ↑Fri Jul 26, 2024 1:52 pm Holger, thanks for testing my questions on dim security and reporting back.

There is no dimension security in place!
Only Element and Cube Security in use.

Final Feedback:
After some more testing it looks like that the behaviour is the same as with SubsetDestroy.
If the Subset is used in another View and options (include Subsets =1, overwrite =1) are set, the function fails and executes a rollback. (The error message is not very helpful)

It works replacing a subset too as long as it is not in any other view...