Planning Analytics with Watson

Expand all | Collapse all

Putting a lock on element in PAW?

  • 1.  Putting a lock on element in PAW?

    Posted Thu February 28, 2019 04:59 AM
    I love that we are able to do almost all the admin stuff from Architect in PAW but I have not yet found out how to place a lock on an object (without a process).

    We often place a lock on previous versions or historical periods but I cannot find this functionality supported by PAW. Am I missing something?

    ------------------------------
    Jesper Poulsen
    ------------------------------


  • 2.  RE: Putting a lock on element in PAW?

    Posted Wed March 06, 2019 05:55 PM
    Hi Jesper,
    In TM1 model, you can change the element security making certain time period read only. Is that what you mean by 'lock on an object'?

    ------------------------------
    Tom Kim
    ------------------------------



  • 3.  RE: Putting a lock on element in PAW?

    Posted Thu March 07, 2019 04:14 AM
    Hi Tom Kim
    It is not element security that I'm looking for. It is the "hard" lock functionality that ensures that nobody - even administrators - can update data for the locked element.

    ------------------------------
    Jesper Poulsen
    ------------------------------



  • 4.  RE: Putting a lock on element in PAW?

    Posted Fri March 08, 2019 09:36 AM

    He's asking about this:

    https://www.ibm.com/support/knowledgecenter/en/SSD29G_2.0.0/com.ibm.swg.ba.cognos.tm1_ref.2.0.0.doc/c_id__4098lockprivilege.html

    Where one can lock an element so that no one can modify it until the server is cycled or an admin releases it.  Think like what happens in Contributor when a person locks a node, but this is directly against an element in a dimension, a dimension itself, a cube, etc, etc.

    I couldn't figure out how to do this in PAW myself but I will ask if it's at least on the roadmap to replicate the functionality in PAW...



    ------------------------------
    Christopher Jubinville
    Planning Analytics Advocate
    IBM Business Analytics
    cjubinvi@us.ibm.com
    ------------------------------



  • 5.  RE: Putting a lock on element in PAW?

    Posted Mon March 11, 2019 05:55 PM
    Hi

    You can do this by running a TI process from PAW. 

    First in Architect, go to the subset editor right click an an element, select security and lock. In the background this will create an }ElementProperties_<dim name> cube. Repeat the process and unlock the element, since all we wan't to do is to get TM1 to create the }ElementProperties cube.

    Write a TI process that gets the name of the current user using TM1USER and which then stores this in the }ElementProperties cube for the dimension at the intersection of the element and the LOCK measure. That will lock it.

    In PAW use an Action Button to call the process.

    Unfortunately PAW Action Buttons cannot get a parameter from Excel which is an absolute show stopper for us in terms of migrating from TM1 Web to PAW.

    However you can set up a prompt that will allow a user to pick an element from the dimension and that can be passed as a parameter to the TI process. That will probably be good enough for what you want in this case.

    Regards

    Paul Simon

    ------------------------------
    Paul Simon
    ------------------------------



  • 6.  RE: Putting a lock on element in PAW?

    Posted Tue March 12, 2019 04:16 AM
    Hi Paul
    Thanks for the input. I was looking for a way to do this without a process similar to what we have in Architect and that functionality is still not in PAw.

    ------------------------------
    Jesper Poulsen
    ------------------------------



  • 7.  RE: Putting a lock on element in PAW?

    Posted Tue March 12, 2019 04:32 AM
    Hi Jesper,

    I would log a enhancement request in relations to putting a lock on element in PAW

    IBM How to submit a request for enhancement (RFE) for the IBM BigFix products - United States
    Ibm remove preview
    IBM How to submit a request for enhancement (RFE) for the IBM BigFix products - United States
    Steps on where and how to submit and track request for enhancements (RFEs) for the IBM BigFix family of products.
    View this on Ibm >



    ------------------------------
    paul YOUNG
    ------------------------------



  • 8.  RE: Putting a lock on element in PAW?

    Posted Tue March 12, 2019 06:36 PM
    Hi Paul at IBM

    I think that IBM are failing to understand what most customers would expect. This is functionality that was already available in Architect and has probably been there since version 7. I appreciate that it may take time, but I would expect that if IBM are serious about replacing Architect with Planning Analytics Workspace, then they would be automatically incorporating all the functionality that is in Architect into PAW (possibly in a different way but still the same functionality). IBM should not be asking customers to raise enhancement requests to get functionality into PAW that already exists in the products that PAW is intended to replace.

    I could live without being able to lock things from the Set Editor in PAW, which is the equivalent of the Subset Editor in Perspectives/Architect from which you can do this, since you can work around that using a TI process in the manner that I described.

    However, in order to be able to migrate any of our existing TM1 Web based applications to PAW we would need to be able to pass in parameters from an  Excel range to Action Buttons, which you can't do.  We want to be able to use PAW because TM1 Web does not support Hierarchies, but we can't.

    Regards

    Paul

    ------------------------------
    Paul Simon
    ------------------------------



  • 9.  RE: Putting a lock on element in PAW?

    Posted Wed March 13, 2019 09:49 AM
    Hi Paul Simon, Paul Young

    While someone else takes a look at your locking request, I wanted to respond to the Action Button requirement you mention at the end of your post. It's long overdue, but we've added the ability to call a TI script from a button in PA Workspace in Update 39. It's a downpayment on a feature that we intend to grow.
    In its initial release the book author can supply the parameters to the script or prompt the end user with a dialog when the button is clicked. The book author can set up dropdowns and other UI controls in the prompt.

    I'm writing a blog entry as we speak for this new feature, but in the meantime, you can check out the announcement in the new features.

    As you mentioned in your post, today in TM1 Websheets you can supply the value of a parameter by refering to an Excel cell. PAW books don't have fixed grid co-ordinates, so we'll have to implement other ways to automate the passing of values from the face of the report to the TI script. An enhancement we're looking it is the ability to pass parameters via the book synchronization feature. This would allow prompts to be satisfied by a dimension selector in the book. Today though you may want to consider sourcing the values from a parameters cube and then putting single cell widgets in the book to populate that cube.

    I hope this helps with your Action Button request. I'll try to edit this post with a link to a more detailed blog as soon as it is published.

    Paul Glennon



    ------------------------------
    PAUL GLENNON
    Offering Manager, Planning Analytics
    ------------------------------



  • 10.  RE: Putting a lock on element in PAW?

    Posted Wed March 13, 2019 11:42 AM
    Edited by Cyrus Rashedi Wed March 13, 2019 11:44 AM

    Hi Paul Glennon,

    Regarding your statement, "An enhancement we're looking it is the ability to pass parameters via the book synchronization feature" --- this would be great to supplement the existing functionality for PAW TI Action buttons released in PAW 39.

    In my opinion, this investment would help to eliminate the need to utilize Excel for building user interfaces, which is no longer fit for purpose, especially given that today's modern applications are lightweight and powerful web-based apps. It would also help further the adoption of Planning Analytics since not all developers and end-users would need to be intimately familiar with TM1 and Excel's nuances, thereby increasing self-sufficiency and ensuring Planning Analytics is keeping pace with its competitors in the market. I'm not saying, "get rid of Excel," rather, re-think how Excel fits into the picture with Planning Analytics.

    With respect to what is currently available in PAW, I agree that passing parameters values stored in a "Control Panel" cube satisfy the requirement until native PAW action buttons are further developed. What's nice is that a PAW book can contain a cube view (Exploration), along with an action button so users can update the values in the Exploration, and then click the PAW Action button to run a process or have the action button prompt for user input…all without using Excel.

     



    ------------------------------
    Cyrus Rashedi
    ------------------------------



  • 11.  RE: Putting a lock on element in PAW?

    Posted Thu March 14, 2019 04:15 AM
    Why do people still use excel on the web for tm1? Because they can find a way to solve most UX challanges. Not always elegant but it works. 

    While I agree with the feature requests, the development speed is just too slow. It took how long to get action buttons? 

    Customers would be much better served by providing open access (programmatically or directly in the UI) to componets like the synchronization framework.

    Allow users to access the values in dropdowns, manipulate them, and pass them to other objects (views, cell widgets, action buttons,etc). It shouldn't be hidden and work only on dimension matching.

    PAW needs to adopt a more open transparent usage pattern if it wants to stay relavent. A simple model where users can set and retrieve values to control widgets would go a long way!

    For example, I still need to use a dynamic report if I want to select a consolidation from a drop down and have a view show its descendents on the rows of a view, why?

    ------------------------------
    Ryan
    ------------------------------



  • 12.  RE: Putting a lock on element in PAW?

    Posted Thu March 14, 2019 12:04 PM
    Edited by Cyrus Rashedi Thu March 14, 2019 12:07 PM

    While I think we all agree that PAW development has been slower than we hoped, I'm sure there are many factors at play. As developers, having a more open and programmatic access to PAW's capabilities would make our lives easier, but IBM also needs to satisfy the average users that don't want to always "customize TM1 with APIs."

    We know that TM1Server at its core is a legacy system going through a major transition. From Day 1, it was not originally "born on the Cloud," fully REST-compliant, vanilla MDX, etc., so it takes time for TM1 to be modernized. Staying positive and providing constructive and continuous feedback will ensure a positive outcome for all parties involved.

    And we should always remember that, "Ultimate flexibility leads to infinite complexity."

     



    ------------------------------
    Cyrus Rashedi
    ------------------------------



  • 13.  RE: Putting a lock on element in PAW?

    Posted Thu March 14, 2019 12:54 PM
    Edited by Ryan Clapp Fri March 15, 2019 02:18 AM

    It is not about API access, I don't want to write complicated code to get PAW to do things. I want PAW to support common TM1 report design patterns (without excel), and was only suggesting a way to do so.

     

    If PAW is  primarily a data exploration and modeling platform, then it is doing a good job. If it is a tool to design custom UIs to interact with your TM1 models, it has a long way to go.

     

    When a tool has always prided itself on ultimate flexibility, excel and TM1, adding components that do not maintain that standard can be frustrating for users.

     






  • 14.  RE: Putting a lock on element in PAW?

    Posted Thu March 14, 2019 01:22 PM
    Hi Ryan,

    I think I'm largely in agreement with you that the synchronization model has room to grow. It could benefit from listening not just to other selector widgets, but user clicks within widgets. I think the example you've described above is a master-detail synchronization. I can see building a dashboard where users click on a row in one table and it changes the context of another table or chart.
    I think we might also want to think about multiple channels for synchronization. Currently a widget is either listening or not. I've seen the requirement for groups of widgets to communicate 
    So, I think I get the requirement for a more flexible synchronization system. It's just a matter of priorities. Hooking the Button parameters up to synchronization is step one.

    Paul

    ------------------------------
    PAUL GLENNON
    ------------------------------



  • 15.  RE: Putting a lock on element in PAW?

    Posted Thu March 14, 2019 01:46 PM
    Agree totally. There is a lot of power there, that when exposed could make some amazing TM1 UI experiences

    ------------------------------
    Ryan Clapp
    ------------------------------



  • 16.  RE: Putting a lock on element in PAW?

    Posted Thu March 14, 2019 07:17 PM
    Hi 

    I am surprised at the number of replies to my aside on the TI Button issue. It wasn't my intention to hijack the original thread. Although possibly if it came to a vote on backing a fix to the Lock element issue for which there is a work around, or a fix to the TI button issue, I would vote for the latter. If an Admin wants to separate this to a different thread please go ahead.

    I probably should have said 'or a facility equivalent to the Excel range facility that currently exists in TM1 Web'. I would agree that a more web based alternative would be preferable, and if it was not currently already under investigation, I would be happy to raise an enhancement request for that since it is a genuine enhancement.

    I did click the earlier link to new features that Paul Glennon provided but just encountered an error message telling me that I didn't have rights to access that content. It is possibly referring to the latest new features guide? 

    We haven't as yet got PAW working fully. You can see my post on the independent tm1forum for the reasons why. The upgrade from 10.1.1 to PA 2.0.5 has been the most painful we have ever had to go through and has involved re-writing large sections of the application. There are still some port and certificate issues that need to be resolved. We therefore haven't had much time to experiment with it yet. Can you confirm that a TM1 Web sheet embedded in PAW which has a TI Button that references an Excel range will work? We have tried upgrading some of our existing Perspectives sheets in PAX but have found that the TI Button Converter does not work. We have raised a PMR for that.

    We would probably want to move to a web based TI button at some point but we cannot simply abandon our existing apps which have been developed over several years. Therefore we need to be able to transition over gradually. We cannot simply rebuild everything in PAW, particularly as PAW does not yet have the necessary functionality.

    The typical use case is that a user selects a Cost Centre, and the grid then displays data related to that Cost Centre, and the user then updates that data and clicks a button to Submit that data for approval. (I have been developing with TM1 for 20 years and I have yet to encounter a case where a customer wants to use the built-in workflow, so this is typically what we build). Having a TI button that only prompts them to select the Cost Centre at the time they click the Submit button won't work. The selection needs to be independent of the TI process.

    Certainly using a small cube with dimensions of }Clients and }dimensions to store the last selected element for each user for each dimension and being able to reference that as a parameter in a PAW TI Button would be a partial alternative. I don't believe that is currently possible so I am assuming that Cyrus means that you would need to have a TI process with no parameters and use a CellGetS in the TI process to get the parameter value? If so that does not appeal to me as it is then not clear just by looking at the TI what parameters it will accept. However, I believe that Cyrus was only suggesting that as a stop gap solution.

    Our existing TM1 Web sheets already use a similar technique to make a SUBNM function default to the value that the user last selected, but also having the ability to change that value, and pass that value into a TI process.

    I would want the result of the Set selection widget to be something that could be referenced in a PAW TI Button, either by the synchronisation feature, or by being able to name them and reference that name.

    I would want the ability to optionally set the initial value for the Set selection widget to :

    a) The last value that the user selected, even if in a previous session, eg defaulting the selection in a list to the Cost Centre that the user last selected on the basis that many users will only ever work on one Cost Centre.
    b) The value from a reference cube, eg most systems have a cube that holds the current period. We would want the period selection to default to that, rather than simply the last period the user selected, as the period would typically be updated in a month end rollover process, and when the user next went in, they would want the default selection to be the new period.
    c) No initial value. We typically handle this by adding eg a z_Select Comparison element to the dimension and selecting that as standard.
    d) A value from a named Set, so, taking the current period example in (c), it is sometimes better to default the initial period to the current period by referencing a named Set which is updated by the month end rollover process, rather than referencing the value stored in a control cube, since that then makes it easier for the user to select a different period if that is appropriate for them. For example, they might want the sheet to default to the current period but have the ability to select a prior period.
    e) A calculated value, typically something like string splicing, or attribute lookup.

    The above are just some examples. Other developers probably have additional use cases. Overall my gut feeling is with Ryan. I don't believe that all the possible approaches can be handled by a simple synchronisation model, and the current approach of picking at the time you click the button won't do. There needs to be some sort of programmatic approach. I would certainly not suggest that everyone should have to learn the REST API to use PAW. However, the ability to name widgets and reference them is the approach used in rival tools such as Tableau. They also have macro language similar to that in Cognos Analytics. However, the use case for Tableau is much simpler. It is purely a reporting tool. We should not be trying to emulate that. TM1/PA is typically used for Budgeting, Planning and Forecasting with real time re-consolidation, recalculation and Reporting. This is a much more complex ask. It is not just about running a report and retrieving data. It must be possible to build an application that will lead a user through their month end data contribution tasks and which will manage workflow, review and sign offs, none of which are required in a pure reporting tool like Tableau. I don't think that IBM should concentrate on trying to emulate Tableau with Planning Analytics. They have Cognos Analytics for that. The value proposition for Planning Analytics is quite different. 

    If the aim is to provide an alternative to Excel, ie one that responds faster and does not limit you to having columns the same width all the way down, then one question I would pose is how it will be possible to generate a pack of Excel workbooks or other offline content for auditors. With our Excel based sheets, we typically automate this using VBA. However, this will not be possible in a Web based PAW book. I am sure that there is basic bursting functionality, but having some sort of programmatic access might be needed in some cases, eg only burst those that have a status of Finalised. VBA is not going to be an option to interface with PAW, and your average accountant is not going to master JavaScript even if PAW did expose an interface for this. Therefore, how can something like that be done?

    Having been a bit negative, I would like to say some positive things. IBM have done an excellent job with the core Server components. The new hierarchy approach gives the flexibility of a Data Warehouse to add new splits, and possibly more so, while still retaining the speed of MOLAP. We have converted all existing processes to use Temp Views and Subsets and that has brought about dramatic reductions in locking with consequent improvements in query response times at peak month end periods. Improvements such as Parallel Interaction, and Multi-Threaded Queries have dramatically improved performance, particularly around the ability to update cubes with forecasts and see the results of that in real-time - something that query only reporting tools cannot do. Asymmetric Rows and Columns show a lot of promise. Having made such progress at the back end, they now need to move faster to make the front-end development deliver on that.

    Regards

    Paul Simon

    ------------------------------
    Paul Simon
    ------------------------------



  • 17.  RE: Putting a lock on element in PAW?

    Posted Thu March 14, 2019 08:38 PM
    Hi Paul Simon, 

    All excellent suggestions for further developing the PAW synchronization framework, and integrating with TI. It's clear that IBM has more work to do in this area, and I think what you've outlined would go a long way toward being able to move away from Excel as the primary tool for developing the UI/UX. 

    I completely agree that IBM should not be trying to replicate Tableau and pure-reporting capabilities in PAW. IBM should absolutely work toward the more holistic goal of facilitating the end-to-end planning process in a single interface. That means a guided user experience/workflow, extensible widgets, advanced synchronization that serves both the interface and TI processes, etc.

    To answer some of your questions:
    1) You can build a PAX action button that accepts Excel ranges for TI parameters. The PAX report can be published and embedded in a PAW book, though the TM1 websheet service is working under the covers for Custom (slice) and Dynamic (Active Form) PAX Reports in PAW.

    2) PAW does have basic functionality to burst Explorations, much like the existing TM1Web functionality that exports to Excel, but with added the ability to specify a single Excel workbook (multiple sheets) or multiple workbooks (single sheet). Granted, this is more data table focused than bursting a highly-formatted report, but I think bursting in general has always been somewhat of a gray area with TM1. One could argue that bursting is better served by a more traditional BI tool such as Cognos Analytics.

    3) Print Report is not yet available in PAX. While this is a bummer, there does exist the PAX API. I haven't yet played around with it, but it does look promising. That might be worth exploring to see if it will satisfy your use case.

    ------------------------------
    Cyrus Rashedi
    ------------------------------



  • 18.  RE: Putting a lock on element in PAW?

    Posted Sat March 16, 2019 12:56 PM
    Hi Cyrus

    Are you working for IBM or a customer? 

    The VBA support in PAX is quite comprehensive and could be used for bursting. However, whereas in TM1 Web there is a 1:1 relationship between a TM1 Websheet and a Perspectives Excel Workbook, the same is not true of PAW.

    While dumping out reports for audit purposes is not particularly value adding it is, in my experience required whenever TM1 is used to produce financial accounts.

    This can be automated with Perspectives or PAX because they are Excel based.

    However in PAW, the bursting tends to relate to individual data tables rather than the whole sheet/canvas. It is likely that any canvas that shows more than one grid will have a separator selector based on the key dimension for bursting, typically Entity, for Financial Accounts. What is needed is the ability to burst based on a separate selector rather than on individual grids.

    Regards


    Paul Simon

    ------------------------------
    Paul Simon
    ------------------------------



  • 19.  RE: Putting a lock on element in PAW?

    Posted Tue March 19, 2019 12:45 PM
    Hi Paul, 

    I've been both a customer of TM1, and am now a business partner.

    Yes, PAW bursting is more individual data table focused . I agree it would be nice to control that at the workbook level, with the ability to cycle through multiple selector widgets for different dimensions.

    ------------------------------
    Cyrus Rashedi
    ------------------------------



  • 20.  RE: Putting a lock on element in PAW?

    Posted Fri March 15, 2019 04:20 AM
    Hello,

    IBM seems to be making developments based on commercial impact and advertisement rather than the needs of existing customers.
    The developments seem to be a race both to the upgrades linked to the first point and to the implementation of indispensable features that had not been anticipated.
    The result is a mediocre quality of the supplied PAW versions and an important validation work before any versions are taken into account.
    It would be advisable I think that the developments are rather slowed down, focused on concrete needs and take the time to be tested properly.  
    In reality, customers cannot afford to change versions every two months on sometimes critical systems.

    Frederic Arevian

    IENA Consulting

    Mobile : +33 (0) 6 47 53 45 70
    Fax      : +33 (0) 1 78 14 13 40

    32, rue ARAGO
    92 800 PUTEAUX

    farevian@iena-consulting.com

    www.cabinet-iena.com






  • 21.  RE: Putting a lock on element in PAW?

    Posted Fri September 27, 2019 08:14 AM
    Thank you for this information, locking with process is easy in this way.
    However, is there a way to unlock as well? I tried with the same approach, but I cannot put an empty string back to the LOCK measure in the }ElementProperties_<dim name> cube because it is, well, locked also for administrators.

    The only way I know to unlock is through Architect, is there another way at the moment?


    ------------------------------
    Jonas Olme
    ------------------------------



  • 22.  RE: Putting a lock on element in PAW?

    Posted Fri July 02, 2021 02:04 AM
    Hey Jonas,
    You need to put CubeLockOverride(1) in your TI Prolog before setting the value.  This will, as it states, override any locks currently in place.

    On a side note, and for all other members, I have come across an issue which I am currently in discussions with IBM support over.
    Scenario:
    I use a Lock to stop entry to our plan versions once instructed by the Planning Manager.  I do this by placing the string 'Admin' or my user name in the LOCK member of the }ElementProperties_dimension cube.
    We recently discovered that one user was able to change values against this locked element.  On further investigations we found that it was because he was changing the dimension hierarchy to an alternate hierarchy (in this case the Leaves hierarchy) and the lock did not apply.

    I believe this is a defect, as it defeats the intended purpose of placing a lock on an element.
    Anybody experienced this or have any thoughts on this matter?

    ------------------------------
    Craig Sawers
    ------------------------------



  • 23.  RE: Putting a lock on element in PAW?

    Posted Sat July 03, 2021 08:16 AM
    Hi Craig

    Like you, I would expect that if you lock a base level element, which in any case is the only type of element that you can change, then it should be locked across all hierarchies. Unfortunately this is not the only case where the Leaves hierarchy does not operate as expected.

    Having said that I have added Named Hierarchies to most of my dimensions, but have not found a need for it in the Version dimension. You could perhaps regard Forecast vs Budget as a Named Hierarchy, but I have chosen to leave it as an Alternate hierarchy. By definition the Version dimension is not one in which it would make sense to consolidation versions, except for variance calcs, unlike eg the Cost Centre dimension where it does make sense to have a conventional consolidation hierarchy. So potentially, one way around the problem is to remove the Named Hierarchy from your Version dimension.

    You seem pretty experienced so you have probably already identified that you could put the lock onto both the Classic hierarchy and the Leaves hierarchy and possibly you may also need it on every Named Hierarhcy. When writing to }ElementProperties putting Leaves:<Element> for the element parameter should work. It certainly does with }ElementAttributes.

    The other approach that we use is a security based approach, whereby eg our Forecast version is made READ only when forecasting is closed via }CellSecurity. All archive type versions are always read only via }ElementSecurity. This does mean that we need to put additional checks into our TIs to stop a user bypassing security by running a TI, but for the version level that is relatively simple. We have a control cube where the person running the forecasting puts a 1 to close the forecast (via a process). That triggers a rule in a }CellSecurity cube on the entry cube which takes effect immediately and makes the version read only. When the 1 is removed by running the forecast open process users can again write to the forecast, but are still subject to normal security controls by Cost Centre, etc. Any process that would amend the forecast or related workflow then just has a check to see if the flag is a 1 and if so it throws an error saying that the forecast is closed.

    Regards

    Paul Simon

    ------------------------------
    Paul Simon
    ------------------------------



  • 24.  RE: Putting a lock on element in PAW?

    Posted Sun July 04, 2021 06:34 PM
    Thanks Paul,
    You are right, I can do without the Named Hierarchy in the Version dimension, so I will follow this route this time.  I did immediately amend my 'LockVersion' TI to set the cell security in the 'main' planning cube, however our model is quite complex with several 'support' cubes that build up the plan from various Entities and very different business lines, which would involve creating and setting many }CellSecurity cubes. 
    I do not use }ElementSecurity (but this is just because I always forget to set security on new elements, however I could write a TI that sets this).
    With }ElementProperties, my test showed that using the named hierarchy did not make any difference.  The Leaves member was still able to be written to.

    I use Lock on several dimensions (Entity, Business Line and Financial Period are just a few) for various reasons and these cannot do without their named hierarchies, and again, are used in nearly all cubes) so it would be nice if IBM addressed this issue.

    I am interested in your statement 'That triggers a rule ...' - am I correct in assuming you have a chore that runs periodically to check this flag?  Otherwise I would appreciate a lesson in event driven programming in TM1.

    Again thanks for your reply and insights. 


    ------------------------------
    Craig Sawers
    ------------------------------



  • 25.  RE: Putting a lock on element in PAW?

    Posted Sun July 04, 2021 11:34 PM

    Hi- Just to add to the discussion, have you tried using Security Overlay to lock the elements by any chance? Just curious how that would behave in the current scenario.

     

    Regards,

    Amin Mohammed

     






  • 26.  RE: Putting a lock on element in PAW?

    Posted Mon July 05, 2021 12:18 AM
    Thanks for your input Amin,
    I have never used the Security Overlay before, but had a look at it after your message.  Unfortunately there are 3 issues with its use:
    1. I would like to 'lock' out the administrator users as well.
    2. I would like a visual indicator that shows the cell is locked (using ElementProperty Lock greyed out the cell, but unfortunately did not allow Trace Cell either! not sure why they blocked that feature).
    3. There are 26 support cubes with the Version dimension that need to be locked, so using the SecurityOverlay on cubes although a little easier, is akin to setting the cell security on each cube.
    Thanks for the hint though.  I will store this away in my personal KB as it may be useful in other scenarios.It was nice to be able to just lock the Version element and be done with it.
    Regards,

    ------------------------------
    Craig Sawers
    ------------------------------



  • 27.  RE: Putting a lock on element in PAW?

    Posted Mon July 05, 2021 06:27 PM
    Hi Craig

    By triggers a rule I just meant that there is a rule in the }CellSecurity cube which says if the central control cube has a 1 in measure 'Forecast Read Only', then it sets the Cell Security for all Groups on the Forecast version to 'READ',  CellSecurity changes take effect immediately, by comparison rule-driven ElementSecurity always requires a SecurityRefresh before changes take effect. CellSecurity overrides ElementSecurity, so effectively, by setting one flag in a control cube in our case called N_Info, it prevents any non-Admin user from entering forecasts. We have finer granular control during forecasting where the workflow cubes control access so that, as soon as a cost centre is submitted a rule in the cell security cube sets the security on just that cost centre for forecasting to READ. The Forecast Read Only is more to stop forecasting across the board. Those processes that can load into the forecast need additional checks to ensure that the forecast is not read only, and that the cost centre is in the Contribute workflow state, and not a later review state. This prevents a user from bypassing security by running a process which would obviously run as though it were an admin and would still be able to write to the version.

    Whether this approach can work for you will depend on your model. In our case there is only one input cube (actually two but it is slightly different case). I think that even if you have half a dozen input cubes it is still feasible. 

    Regards

    Paul Simon

    ------------------------------
    Paul Simon
    ------------------------------



  • 28.  RE: Putting a lock on element in PAW?

    Posted Mon July 05, 2021 06:47 PM
    Edited by Craig Sawers Tue July 06, 2021 08:40 PM
    Thanks all for your input on this matter.
    IBM Support have come back this morning with the following...

    I have submitted this to development and they have come back saying there is the potential for this to be a defect.They need a couple more days to review and will then provide an update.

    I like the idea of a flag in a central control cube ( I already have one which controls other planning specifications ), failing the element being able to have a LOCK on it that is effective against all hierarchies.  However, because I have so many input cubes, I will go the route of the ElementSecurity and implement a nightly process that checks for new elements and sets the security as appropriate.

    Edit: 2021-07-07
    Received this from IBM Support this morning:

    The APAR details are below:

    PH38716 ELEMENT LOCK FUNCTIONALITY NOT WORKING AS EXPECTED WHEN USING MULTIPLE HIERARCHIES


    Regards,



    ------------------------------
    Craig Sawers
    ------------------------------



  • 29.  RE: Putting a lock on element in PAW?

    Posted Wed March 13, 2019 09:56 AM
    Dimension, Cube, and Process lock actions from the PAW tree are currently under development.   Development work on setting element locks from the set editor has not yet begun.

    ------------------------------
    MARK Kiel
    ------------------------------



  • 30.  RE: Putting a lock on element in PAW?

    Posted Fri March 15, 2019 09:26 AM
    Hi Mark
    Just want to be sure that I understand this correctly. It will be possible to lock a dimension, a cube or a process from the PAW tree but not on single elements.
    Rgds,
    Jesper

    ------------------------------
    Jesper Poulsen
    ------------------------------



  • 31.  RE: Putting a lock on element in PAW?

    Posted Fri March 15, 2019 10:19 AM
    Apologies, I should have been more explicit.

    A dimension may currently be reserved from within the dimension editor in PAW.  The reservation behavior is slightly different from legacy TM1 behavior, in that reservations persist between sessions, and is only available to modelers.  This type of reservation is intended to provide bulk editing and "undo" capabilities for dimension editing.

    Traditional lock behavior is coming soon to the PAW tree (currently under development) , for cubes, dimensions, & processes.  We are not currently working on element lock in PAW, but are considering it.  The PAW tree shows elements (Architect did not), and might be the quickest way to expose it there instead of in the set editor.

    Mark

    ------------------------------
    MARK Kiel
    ------------------------------



  • 32.  RE: Putting a lock on element in PAW?

    Posted Fri March 15, 2019 10:28 AM
    Thanks, Mark.

    I like the idea of having the element lock in the PAW tree so hopefully you will go beyond consideration 😉

    Rgds,
    Jesper

    ------------------------------
    Jesper Poulsen
    ------------------------------