Disable remove category option for Category in Smart UI

Hi All,

We have a requirement where users having edit attributes permissions shouldn't able to remove the category from folders in Smart UI.

Any inputs how to disable remove category option in properties tab for a category in Smart UI.

 

Regards
Devi

 

Comments

  • I've got the same problem. Has anyone found the solution?

  • A similar question was posted to https://knowledge.opentext.com/knowledge/cs.dll?func=ll&objId=72980517&objAction=viewincontainer&ShowReplyEntry=72884411#forum_topic_72884411

    There's a module called 'Restricted Categories' available from Professional Services that may be of interest to you. The linked thread has details for contacting PS for more information.

  • Damion's reply should help you. The new version of the PS module should cover Smart View too.

    There is an API to disable removal of categories in Smart UI. It is used in some scenarios, like "Create Connected Workspace", where caregories pulled from the workspace type are supposed to be non-removable. Only categories added by the user should be removable. However, the core product has no configuration bsed on users, groups or other conditions. If the PS module is not enough, you could develop a REST API extension (form callback) or file a feature request for this feature.

  • Hi, the simplest way is to remove DOM element using js by css selector. This aproach worked fine for us.

  • @Alexandr Arzamastsev said:
    Hi, the simplest way is to remove DOM element using js by css selector. This aproach worked fine for us.

    Hi Alexandr, can you please clarify how you were able to achieve this? As I understand, Smart UI does not allow custom views, so was your solution a Smart UI SDK based extension?

  • Make patch using replace object's prototype feature, loading in with require.js

  • I tried to do this via CSS and got half way there.

    Here is my CSS override:


    /* smart ui header logo */

    .binf-widgets .binf-navbar-brand > .csui-logo > .csui-logo-image {

       background-image: url(binf/../client.svg);

       background-repeat: no-repeat;

       height: 32px;

       width: 400px;

    }

    /* hide remove categories button on tab in smart ui */

    .cs-tablink-delete{

          visibility: hidden;

    }


    /* hide edit pencil in the smart ui */

    .csui-icon-edit{

       visibility: hidden;

    }



    Where you successful with making a Cat & Attr Read Only in the Smart UI with a modest Customization?


    Regards,

    -MC

  • Ferdinand Prantl
    edited February 4, 2021 #9

    The permission to add categories is received by the AJAX call that obtains form schema for the categories - /api/v1/forms/nodes/update?id=:id. There is a boolean property /forms[role_name=categories]/schema/additionalProperties there. If this property is set to false, adding categories will be forbidden. If this property is set to true or not set, adding categories will be allowed. This takes care of showing the only those UI controls, which make sense for the authenticated user. Of course, the category setting call (/api/v2/nodes/:id/categories) has to check for the the same permission and condition it to maintain the data integrity.

    The permission to remove categories is received by the (same) AJAX call as above - /api/v1/forms/nodes/update?id=:id. You will find all categories below the /forms[role_name=categories] object. Categories (form objects) that should not be removable by the user need a property options.removeable set to false. If this property is set to true or not set, removing of the particular category will be available.

    Rendering some attributes read-only is controlled also by the form schemas returned by the above call to /api/v1/forms/nodes/update?id=:id. You will find all categories below the /forms[role_name=categories] object. Fields that should be rendered read-only need a property schema.readonly set to true. If this property is set to false or not set, the particular field will be editable.

    The OT module mentioned in Damioin's post uses the proper technique - to implement the features I wrote about in the preceding paragraphs - modify the form schemas returned by the REST API, including the data integrity in related modification REST calls. And offers a configuration based user groups for it. If you do not want to buy the module, you can write such module yourself, of course. But consider the maintenance costs. By the way, how will you cover the Classic UI, CS Mobile App and other applications that have been and will be built using the REST API, when you just fumble with the desktop Smart UI? You seem that if there is solution that looks faster and cheaper, it is no better, because in the end it will not be faster and cheaper...

    Using CSS to disable some functionality will backfire sooner or later. Buttons and menu items are added to proper places to optimize the user's work. New widgets are created that may include those buttons. You can continue chasing for them, but you should look for soplution that do not require constant maintenance. Additionally, you would not block the code that handles the actions, which is still being executed, which may cause problems, because what you do is not expected for a customised product. And you will be able to affect Add Category only globally and not targetting specific nodes. And CSS is not declared a stable interface, which means that your code may be broken in any patch or upgrade. If you deliver a solution based on CSS nevertheless, you will increase the maitenance costs for your customer and make their situation with following the OT best practices for software updates and getting an official support more problematic.

    Modifying prototypes of objects that you do not own is forbidden! If this gets discovered when the customer asks OT CS for help, their environment will be declared unsupported and they will be asked for removal of the offending module. If people were overwriting foreign prototypes at will, we would not be able to use our knowledge to understand how the system behaves and such support case will be dragging on unexplained . Smart UI offers configuration and extensions to control its look and feel. Techniques that you know from Classic UI will not work, or at lest will not work well.

    Removing HTML elements that you do not own from DOM is just another way ho to make the UI crash sooner or later. The component that you would be mutilating by it does not expect it. Do not do it.


  • Modding a Classic UI Page with a Appearance (and JavaScript) has been Standard Practice for the Classic UI forever.

    This an extensive common practice.


    The newer way is with ActiveView. ActiveView is a great gift for the Classic UI but Appearances are forever.



    It does seem by design that OT only allows mods to the Smart UI GUI by OScript Developers and has 'locked out' the ActiveView, WebReports, JavaScript Developer.

    Furthermore, there is no ActiveView option for the Smart UI at all. The WebReports Tile requires additional LICs from OT to be viable.




    I remain interested in @Alexandr Arzamastsev approach, despite the warning about OT Support.




    Regards,

    -MC

  • Clarke
    edited February 4, 2021 #11


    This seems related:

    http://pos2007.de/add-a-permanent-footer-header-etc-to-smartui

    (Disclaimer: This requires a modification of app.html. Doing that will put you in the club of villains who intentionally change internal weblingo files.)

    Regards,

    -MC


  • Similar to the Read Only Category Request, today my Client asked to hide the Audit Tab in the Smart UI.

    I can easily do this in the Classic with ActiveView but cannot in the Smart UI. There is no option.


    Is there any alternative to developing a custom module?

    All of my research has led me to believe that OScrpt modules are the only way. Is this correct?


    Regards,

    -MC

  • Yes, hiding the Audit is possible only by a Smart Ui extension (distributed using a CS module) today. There is no administration page to flip some boolean flag. In this case, the Smart UI customisation takes place in OScript. The audit metadata panel can be disabled using the (module configuration) API.

    Create a new OScript module, or use your existing one. Orphan CSUI::Extension to your module and set fEnabled to true. This declares and enables a new Smart UI extension. You do not need any UI extension in this case and you can ignore the other features, that are usually overridden. Override the GetDynamicConfiguration(Object prgCtx, Record request) method to return this assoc:

    assoc{
      "csui/widgets/metadata/metadata.audit.view": assoc{
        "enabled": false
      }
    }
    

    How to make it administrable for the customer is up to you. You can use the prgCtx of the authenticated user to access other APIs.

    The result of the GetDynamicConfiguration method will be passed to require.config({ config }) in Smart UI to provide global parameters.

  • Clarke
    edited July 8, 2021 #14


    The info is valuable but I think OT really needs to think about what they are saying.

    Generally speaking, OScript is not an attractive way to Customize Content Server.

    OScript is really complicated and most Non OT, Non Partner OScript Developers don't make a good module. Then when it comes time to upgrade, the module doesnt work on the new version and ultimately the module gets dropped.

    I have been through this with many Customers.


    WebReports and ActiveView are the correct way to Customize Content Server.

    For ActiveView, there is a specific example report that shows how to remove things from the Function Menu.



    As for your example, as I am not into creating my own OScript module, however there is another option.

    Illegal patches! Custom Patches to patch CORE OT OSpaces.



    Is that the future of the Smart UI 'config' Some illegal text file I to shove in to pass the Smart UI switches because OT Development doesn't want to make any more GUI in Admin.Index ?


    Smart UI Search Stemming is a PERFECT example of this lacking control that the Classic has.


    My Client is running v21.2 (latest) and nothing has changed with 'controlling' the Smart UI.



    If I am successful with the illegal patch, I will post it here so others can 'patch' their Smart UI to hide Audit.



    Regards,

    -MC

  • Ferdinand Prantl
    edited July 28, 2021 #15

    This is a forum where developers help each other solve problems. In is not watched by the management. The proper way to ask for a better configurability of CS Smart UI is filing a case at the OpenText Customer Support. They communicate with Product Management, which in turn decides where to invest.

    Patching files deployed by the CS installer and keeping them patched after Systenm Center applies new official patches means more effort than deploying an OScript module with a change to Smart UI default settings. (If such default settings can be changed, which is not always.)

  • @Clarke OScript is a perfectly valid option in many cases for operations that can't be done any other way, such as adding a subtype, but I agree that there are issues with quality and upgrade debt, as there are with any development approach.

    I've seen, and cleaned up after, several major WebReport/API driven solutions fail due to the design of the solutions where an OScript approach resulted in a better / more performant solution for the client.

    At the end of the day, OScript, REST, WR, CWS etc are all valid ways of doing something in OTCS, you just need to find the right tool for the job, your teams skillsets and that of the client.


  • I do want to go into the Pros and Cons of Developing a Custom Module for Content Server. My point in commenting on this thread is draw attention that options for changing GUI of the Smart UI are greatly limited vs Classic.


    In the Classic UI, the Solution Developer has Appearances, Custom Views, ActiveView and WebReports.

    ActiveView comes with a robust set of templates for UI Customization making possible to hide/remove things but only from only the Classic UI.


    In the Smart UI you get the WR Tile and HTML Tile and CSS

    The WR Tile comes with Nodes Table and TableReportView.



    Long story short, it is much easier to Customize the UI of the Classic than it is to Customize the UI of the Smart. That is the point of my comments on this thread.


    This was a discovery for me as this wasn't exactly clear. It is crystal clear to me now.


    What I was looking for was more 'entry points' into the Standard Browse widget that allow for more Consulting tweaking.


    That is sorta what xECM does, but only via 'Widgets' (aka starting the Smart UI outside of OT). It is possible to open the 'Widget' with extra switches to hide stuff, like the Folder Child Count, or the back button, etc.


    But there is no Page Overrides / ActiveView equivalent in the Smart UI.


    In the scenarios raised by the Client (Read Only Category, Hide Audit Option) I cannot achieve these in the Smart UI without OScript Development.


    At the end of the day I guess Smart UI is much more rigid than the Classic and doesn't create opportunities to extend it unless you are an OScript Developer. I hope this will change as Smart matures.


    ActiveView and WebReports is version agnostic, lowest entry bar way to Customize Content Server. I hope the Smart UI roadmap will eventually include more ActiveView-ish functionality.


    Good news is I don't think the Classic UI is going anywhere.


    -MC

  • @Clarke agree with your comments about the current state of Smart UI v Classic UI for configuration.

    While some development for Smart UI is OScript based, the vast majority of the coding is done in JavaScript rather than OScript see https://www.opentext.com/TrainingRegistry/course/details/2928.

  • @Greg Griffiths

    some SmartUI Pioneers like Christopher Meyer, Mathew Barben, Pierre Nocera & AnswerModules people(Patrick Vitali), are all well known here and in external blogs so I am not trying to find them here, just use the OT SUI SDK to just hook and then do all manipulation in other more industry-standard JS frameworks. The Oscript is just to get the system to recognize the extension. If you find an existing REST API insufficient you need Oscript to fill in the gap but REST API is not considered part of SUI development.I know enough to do the "Hello World" things in SUI never had any need to do any cool things but one of these days I may get into it. Anyways at this point, the SUI is a hard lift for anyone not knowing core JS libraries(you cannot keep up with them as mobile changes day by day). Perhaps enough people complaining will make OT provide more hooks for commonly done tasks.@Reiner Merz helps a lot of people in this.


  • There are certainly a lot of great blogs out there about OScript, REST, and the Smart UI.

    Maybe one day I will create my blog and dump all the XECM and WebReports tricks I have horded up during my career.


    And, like you said, they just use the OScript as a tool to crack open the underlying JavaScript framework that powers the Smart UI. So not really OScript, just UI stuff. But the OScript is needed as an entry point.


    Some of this is covered by OT as well. Please see my comment about xECM and starting the Smart UI outside of OT. Working with my Client we did extensive testing opening the BWS.

    Despite all the hacks, we just went with IFrame /xecm vs /app

    /xecm hides the bread crum which is essential for BWS/XECM.



    In my own Practice, I'm not looking to create new 'Product' or an 'Extension' to Content Server. My Style ECM is always to avoid OScript at all costs.

    Most I will do is DEV Custom WebReport tags to extend WebReports. But never OScript.

    OScript isn't needed to extend the REST API in some cases. You can do it with just a WebReport.

    Calling a WebReport via REST is a great feature of Content Server (because it avoids OScript Development).

    Mentioning Reiner Merz, he has a blog post about how to get your own JavaScript on the page without OSscript too. Also forbidden by OT (and not OT Cloud Supported) but at least you can see the 'big names' hitting the same block I am hitting:


    He makes it own way into the Smart UI by editing Core OT File app.html (which is illegal/forbidden) but as I noted, OT doesn't really leave ways into the Smart UI.


    Regards,

    -MC

  • @Clarke concerning Webreports: dont be to disappointed on the parameter.prompt and the status.screen. Its easier to spawn these controls and then use them in a complete custom widget if you have more than "0" requirements.

    Concerning app.html: I only mention htmlmap and modulemap as useful tools in the Content Server.

    Ways into smartUI: (just for information

    -use the map command of requirejs to replace a js module with your own. This is easy anbd proven and even allows the usage of different module versions. BTW look at Documentum smartUI to see the map n action.

    https://requirejs.org/docs/api.html

    -export a function in an extension point. This is a q&d method to modify things. See https://forums.opentext.com/forums/developer/discussion/comment/958964#Comment_958964 and also the screenshot below. If you want to get rid of smartUI functions, use the second method, Thx to 'Ferdinant Prandl'


    But there is one elephant in the room:

    As the first argument is more for the beauty of the universe (instead app.html is the place to put it in with htmlmap as a little helper and GetDynamicConfiguration is worthy of discussions), the second argument is the usual thing in Content Server. Copy the original js module and modify the copy or (if you are adventurous) inherit the js original module. Anyway, you have to check the functionality after an upgrade. But this procedure is well known to OScript programmers, where core modules can change without warning since decades. So simply extend it to js.

    Short intro (to would-be-villains): htmlmap allows your cs oscript module to replace any cs html page (like app.html) with your own. If you uninstall your module, you get everything in the original state. modulemap is the brother of htmlmap for oscript code. And the twin tools are here since 9.7.1

    -(last ditch) rely on the REST infrastructure and build your own UI (using React or any other framework) or a mixture thereof (happy IFraming, happy interfacing)

    Remarks:

    So in smartUI its useless to dream of ActiveView, Appearances or even thinking of webreports to provide a new smartUI besides simple wr tiles on the most basic level. (Once upon a time I did this with webreports to mimic a complex UI inside the ConnWS widget. Was a proof of concept and was not really useful for production)

    And Yes, it is easier to customize the UI in legacy UI compared to smartUI. But this comparism compares apples with pears and is therefore not directly useful.

    And: OScript is the name of the game at the server side.

  • @Clarke As much as it pains me - @Reiner Merz is right. On the serverside OScript is going to be the most performant way to be.

    Yes, you can create a quasi API using Answers or WebReports successfully - but at the end of the day when they break they are your problem and not OTs - this is why we tend to steer clear of WebReports and aim for an API first approach to things (which has ended up in us wrapping both portions of REST and SOAP APIs together into the same service layer in some of our Angular apps).

    And scaling a javascript service library is waaaay easier than scaling and reasoning about a WebReport based API - let alone deploy one (oh and testing is a bunch easier too).

    Most of the reasons we have the hackey work-around in the wild is because we hoard our ideas. That coupled with a vacuum of documentation and practical use cases to get experiences off the ground means that we don't see more REST API extensions out in the wild. So I would totally encourage more voices in the space.

    Getting back to the core use case that kicked this off - Oscript is likely to be a better fit - as it will ensure consistent behavior for all OT clients (Smart UI, Classic UI, Enterprise Connect)

  • To add to @Mbarben's comments - there were changes in later CS releases for FedRAMP. These include changes to session management and expiry.

    Long and short - though there's been a patch, these changes meant you couldn't consume a non-REST API formatted endpoint via the Smart View code. i..e unless the API URL was of format /api/v1/... or /api/v2/... then an error resulted.

    Sure, you can create a quasi REST API using WebReports, but the above meant you couldn't consume it via the Smart View SDK.

    Anyway......these are the things we learn and bite us.

    @Clarke - at end of day, with all kindness and respect, this topic has now gone off on a tangent to the poster's original question...... 😉


  • The answer the the origin question is that OTPS has a Custom Module that is For Sale and Extends Core Content Server to include a Concept of a Permissionable Attribute.


    OT DEV also includes some bits about how I could achieve these results in OScript using your own Custom Module. There is no opportunity for ActiveView Development in the Smart UI.


    The result cannot be archived in the Smart UI without Custom Module.

    You can sneak in your own JS into Smart UI if you hack app.html or launch Smart UI from your own page.

    Non OT Modules should only come from quality Partners only

    WebReport based solutions are 100% is OT Cloud Ready


    The SmartUI has less opportunity for the ActiveView/WebReports minded Developer


    tl;dr

    If you want a Read Only Attribute in the Classic UI, you can do with ActiveView easily. If you want to Hide Audit Information you can do it easily with an ActiveView.

    If you want a Read Only Attribute Smart UI, buy it from OTPS module or Develop your own Custom Module. There no Smart UI ActiveView equivalent to Category tab Override or Audit tab Override. There are no Smart UI overrides.


    Regards,

    -MC

  • @Clarke You have a point here.

    It has always been a challenge to find Webreport or Oscript developers on the Market.

    Now with SmartUI, it looks like OpenText followed the same model. To ramp up on the SmartUI SDK, you must ingest thousands of pages of books of various Javascript frameworks. This is not appealing at all.

    OpenText does not provide an easy ramp-up to develop on top of Content Server as Microsoft, Google and others are able to offer. Simply look at the Game development industry, they have amazing tutorials that even a 13 yeard old kid can follow (i.e: Unity3D).

    I'd like to know how long it takes at OpenText to train someone fresh from school and how long it takes for him or her to be operational to build robust code.

  • There is some highlights in the PPT that comes with the SmartUI SDK as well as a course, https://www.opentext.com/TrainingRegistry/course/details/2928, that provides the intro similar to the OScript equiverlant.

    Additionally, several partners are offering their own training as well.

    From my point of view, I am seeing SmartUI in a similar bucket as REST or CWS development, in that the main development skillset for this will come from JavaScript resources, who know the frameworks and tools etc, and can be taught a little OT concepts.