orphan Oscript

Lorenzo Maggio

Hi
I need to modify Action-PermissionsView in WEBNODE::WebNode::DefaultWebNode.
I did the orphan of Action-PermissionsView but when I do debug it doesen't execute my function
have you suggestion ?
thanks

Appu Nair

Have not done anything related to this but there are several steps in Oscript one takes to make it known to the main content server engine that Run my code instead of OT code. That too sometimes is difficult because OT Patches are loaded after the main OLL is loaded so if there was a patch replacing the code then it would take precedence. usually many Objects have a .fEnabled to indicate the orphan needs to run then again many overrides are accomplished in many different ways. If you post the steps to what you did several Oscripters in this forum will be able to help.

Lorenzo Maggio

I did:
1) orphan of WEBNODE::WebNode::DefaultWebNode
2) override function __init, enable, Action-Permissions
3) added the reference in the global

I did the same steps starting of the orphan WEBNODE::GlobalMenus::Enterprise and it working well.

What's the difference?
It's possible to have two __init in the same project ?

thanks
Lorenzo

John Simon

Are you in CSIDE or the old builder? Also you say you override __init, what did you do in there? Without knowing too much, I suspect the problem is your are over-riding the wrong object. If you look at default web node (so in CSIDE, Module Explorer tab, WEBNODE:WebNodeRoot:WebNode:DefaultWebNode), right click and show in hierarchy view. Notice that nothing is inherited from this node. Now if you do the same for WEBNODE::WebNode you will see all kinds of things are inherited. Is there a specific subtype you are trying to debug?
Cheers...

Igor_Zottich

Hi John,
We are using CSIDE.
I'm doing this exercise together with Lorenzo.
We have orphanned the WEBNODE::webnode and so when we click on source --> override features we can see the ACTION-PERMISSIONS method.
We have selected it and have set the fEnbled to true and have also overridden the __Init() so to initialize it.
Then we have set a breakpoint in the code expecting the CS to use our overridden function instead of the original, but it is still using the original ACTION-PERMISSIONS method so we are missing something but we do not understand exactly what.
Any help is very apreciated
Thanks
B/R
Igor

Appu_Nair1

John will probably explain it better than I do but here is the Oscript Guru Chris Webster saying similar things
Read the thread where Chris Webster explains the RunTime nature of code https://forums.opentext.com/forums/discussion/258793/overriding-core-modules-scripts#latest essentially you will use the __init() to fire yours only at RunTime.Similar approach in Customizations_RT as well

John Simon

As Appu and Chris mention there are several different methods to do overrides. However if you have orphaned something that gets registered with a subsystem and you keep the same key then both objects will be registered, whichever object registers last is the one that "wins". RequestHandlers work this way AND so do LLNodes and WebNodes. So if you keep the same key and your module is loaded after the module you orphan from you should be good to go. One thing to keep in mind, after you orphan you will have to stop/start for the change to take effect.

Why are you overriding __Init? I wouldn't think there is anything in there you want to change. And it already calls _SubclassInit if there is some additional work you want to do. Also I go back to an earlier question, are you intending to override a specific subtype OR are you trying to override all subtypes?

Cheers...

sıɹɥɔ

An orphan may be defined in OScript for several different reasons: to create an object based on another; to change an object's behavior; to establish a reference to another object; etc. The effect of the orphaning will depend on what features are overridden, how the orphan is used, but most importantly the details of the original object that is being orphaned. You cannot simply orphan an object in general and expect overrides to have any particular effect.

John and Appu are both expert OScripters, and because you mentioned overriding __Init they may be anticipating that you're attempting to employ an advanced technique (which you probably shouldn't be using :- )

You seem to want to override a WebNode's "Action-" method. Depending on your ultimate goal you might want to try doing this with the use of a WebNodeAction object that you'd add to your ospace. This is described in the CSIDE (Builder) Fundamentals course.

Hope this helps,

-chris

Igor_Zottich

Hi All,

First of all thank you all for your feedbacks.
Just to give you some additional info, we can say that Lorenzo and I have recently taken the oScript course and are now in a phase in which we need to better understand the logic and the techniques for implementing new modules and for customizing existing functionalities.
Since in CS 16.2 an object's permission is managed differently based on the user's permission on the object itself, we wanted to customize this functionality.
In particular, we wanted to change the permission's behavior for a particular user.
What we would like to achieve is that if a specific user clicks on the permission's function menu, we would like to check which user is clicking on the permissions and if it is our specific user we wanted to give him the opportunity to edit the permissions even if he doesn't have the edit permissions enabled. To do so we were thinking to do the action using the Admin's context in the place of the user's context, let the user change the permissions as if he was the Admin user and then set his original context again.
So, as our first step we wanted to override the ACTION-PERMISSION and do all our changes in this section.
We have overridden the __Init() function as in the manual it states that if an orphaned object needs to be enabled and initialized we need to set te fEnabled to true and orphan the __Init() so we thought that to be able to use it in our module we needed to do so, but probably we misunderstood something here.
Last but not least, we would like to override all subtypes even if to know how to override a single subtype would be interesting too.
Thanks in advance
B/R
Igor

Greg Griffiths

this issue can also be caused by a later override / patch replacing your code.

I would be very wary of your use case as giving a user Admin "context" for a specific function is a major risk, especially if the context persists somehow after the function. You may be better giving that user access to a new WebNodeCmd or WebReport etc that shows what they need.

Igor_Zottich

Hi Greg,
I'm not worried about the Admin's context at the moment as this is an exercise just to understand how to do customizations.
Yet, if the issue is due to a later override due to a patch for example how could I find out?
again, if a patch is overriding my customization how can I deal with it? I mean if we need to customize a functionality that is being managed by a patch how can we do it?
thanks
B/R
Igor

John Simon

Igor, You picked a very tough one to start with. I agree with Greg BUT to try an answer your question...

First thing I thought of, what if the user you are talking about has zero access to an object? It will not even be listed on the browse page so that may be an issue. But for now let's assume the user can see the object but does not have "edit permissions" to it. When they click the function menu for the object they will not even see the permissions menu choice. To change this (in oScript) I would orphan the object WEBDOC::DocNodeCmd::Permissions and override the IsEnabled script. There should be no need to override __Init here (at least not yet) because your code should be loaded after WebDoc which means your version of the command should be registered with the subsystem last. In the IsEnabled script make your changes to turn this command on for the user (or users) in question... I would make it work for any user in a specific group (that the administrator specifies in the Admin pages) so this can apply to others without the need for a code change.

As Greg said a patch can override your changes. There are ways of dealing with it (Chris makes reference to it above) but I would not worry about this for now...until you need it I mean. Anyway start with this and we can move on to what happens once the user clicks the Permissions option in the menu.

Cheers...

Appu_Nair1

I will second what @Greg_Griffiths and @"John Simon" said .I once created a "Unreserve" command for people in a specific group who may not be "SA" .Unluckily the code is in 10/971 builder version so I don't remember much of that. But if you have a new webnodecommands for all object types(start with 0 and 144) then you can see code coming to obey your heats whim and progress from there. Using SA context while a server is running and not disposing it can cause all kinds of problems in the long run. I will concentrate on the builder book or SIDE where they show you how to debug the execution chain, that is how I look at studying code many times.

Now with CSIDE (I am pretty sure it could be done with builder but I didn't do it at that time) is to write simple snippets. For e.g this morning just to see a particular registry I put this in a "test.e" and "Ran as Oscript"

Dynamic bb=$WebNode.WebNodes
scheduler.debugbreak()

(in some versions you have to explicitly open the debug perspective, I have to do on mine)

if you look at the "bb" variable you can see many interesting things and what John meant by subtypes the obvious ones being 144 and 0 (document and folder registered by subtype)

Greg Griffiths

@Appu_Nair1 said:
Now with CSIDE (I am pretty sure it could be done with builder but I didn't do it at that time) is to write simple snippets. For e.g this morning just to see a particular registry I put this in a "test.e" and "Ran as Oscript"

Dynamic bb=$WebNode.WebNodes
scheduler.debugbreak()

You can also find this in Application Globals (right click on the Project Name in the Module Explorer window to see it) then just browse the complete list of application globals until you find WebNodes.WebNodes.

Appu_Nair1

If a patch is loaded while the server is running you can put an ECHO("marker") in the patch code you will see that in the object that it is overriding If you see the screencap you can understand that the Attachments Object in WFPackage is the Patch OT is doing. The "pat::Attachments" is an Indicator of how the OT programmer called it while creating the Orphan and he changed the feature GetData .This is I think is the old style patch
New style patches leave a pat file with some instructions but the replacement to code happens in the itself like relevant directories and OLL's so the new code does not have to wait until all is started up.(That is my understanding may not be technically accurate)

If you unlock the Webwork ospace then the patch code will not be seen. As a rule one does not unlock core OT code. So if you were working with a CS with modules unlocked you are seeing patched code.

@Greg_Griffiths I know about the global vars just another way was my intention especially if one wanted to look at registries

Igor_Zottich

Hi All,

I made it to work, actually the issue seemed to be the name of the Object created in my custom module.
When I was first creating the object to override the request handler I was setting a name like MyPermHead which was inheriting WEBDOC::****::YYYYY
As soon as I have called my os file PermHead and the object name PermHead exactly as it is on the webdoc module, the execution of the permissions functionmenu called my overidden requesthandler instead of the original one.

I also had to copy the weblingo files in my custom module so to see the permissions page, although I would have thought that after executing my custom code it would have continued with the original code,
Maybe this is due to the fact that all the other functions are inferited so they are exeuted locally in my custom module instead of the original module, is this the reason?

Thanks to all for your help.
B/R
Igor

John Simon

"Maybe this is due to the fact that all the other functions are inferited so they are exeuted locally in my custom module instead of the original module, is this the reason?" - I assume based on the name PermHead you ended up "overriding" the PermHead request handler? If so then yes, eventually ModHTMLPrefix() should end up being called. If you do not need any of your own HTML files (for this specific request handler) then you can override this script to return the path to the original WebLingo file.
Cheers...

Igor_Zottich

Hi All,

Here I am again.
I went through chapter 13 of the course manual in which it explains on how to find the action being executed when a user clicks on a function menu item or command item.
At the end of the chapter it simply says that once you found the action item you want to change you should not orphan the webnode object but it is recommended to orphan the WebNodeAction object and modify its features.

But in the webnodeaction I can't find the action methods so how can I change their behavior?
I am confused!!!
Any help is very apreciated.
Thanks in advance
B/R
Igor

John Simon

Igor,

I can tell you how I find things like this. In CSIDE, on the Module Explorer, right click on the very top thing (xxxx_server) and choose Global Variables (or however you like to get to Global Variables). In Global Variables page down to and expand WebNode. Find and expand WebNodeActionMultiMap, find and expand fMultiMap. This will list each subtype and which WebNodeActions are "assigned" to that subtype (also a subtype of ? or undefined means that WebNodeAction is "assigned" to all subtypes). From that you can see where the Action lives. Ex: Webdoc::DocNodeAction::Download is in the WebDoc ospace.

Cheers...

Appu Nair

@John Simon you need a picture

sıɹɥɔ

In the previous chapter of the training guide you will have created a WebNodeAction. In particular please see page 12-2, which shows how a WebNodeAction object matches the WebNode method that you're wanting to affect.

(As mentioned earlier, orphaning can be used for multiple purposes. In the case of orphaning the base WebNodeAction the purpose is to create a new object; it's not to override the features of an existing WebNode object i.e. the script you're wanting to change won't appear in the orphan.)