SysModuleReportTable (Table part of the print form).
Thus, for the correct transfer of the entire print form, it is necessary to perform the bindings of all the specified tables. When transferring, make sure all print forms' titles are unique.
More details about the functionality can be found at the following link:
It's a no-code method. You need DB only for step 3 but you can replace it by checking if "ChartWidget...." appeared in the Desktop settings list of strings (Advanced Settings -> enter the name of your new Desktop in search panel -> Left panel with different settings -> Open Localizable strings).
Is there a way that I can control what data Creatio binds automatically when I make saves in the section wizard? I'm trying to make edits to an application and Creatio keeps incorrectly binding a section to a workplace not included in that application meaning I have to always remove the binding before doing test installs, otherwise the install fails.
And I would like to vote for making this functionality optional. We don't transfer Workplaces and binding to our customers - they used to organize workplaces by themselves, so deleting automatic binding is extra headache for us
Currently, there is some hardcoded logic that saves some of the changes into the Custom package regardless of the package that is set as the current one.
For example, when you turn on administration for an object it will save these changes to the Custom package, the same behavior can be seen when setting up a change log for an object.
As a workaround, you can move the created files to the desired package by using the "move to another package" feature in the configuration of the site. We have additionally added this request to an already existing task for our developers to change this behavior in future releases.
Thank you for sending me this article. We already tried this method and it worked on some other grids, but, unfortunately, not for OpportunityPageV2OpportunityProductDetailV2.
Do you have any idea if there's any other method for binding this grid, or if could be an installation from an environment to another?
I updated the values of existing records of an OOB lookup and I want to bind them to my package. When trying to do that is showing me this error:
How can we update already binded data with our new values? I'm having the same problem when trying to bind the columns of sectionlist of an OOB section.
Additionally, in general, there is a general recommendation not to consider the meaning of base values, but to add new ones to the reference and bind them to a custom package. This approach simplifies the transfer of data between environments and helps avoid the hassle after an upgrade or, for example, after re-installing the data bindings in the environment.
Thank you for your reply. I will create a suggestion for our R&D team so they could implement the logic of binding system settings values and OOTB lookup values that are already bound to base packages in the next application releases.
Thank you for finding such a system behavior and helping us in making the application better!
It's not recommended to bind the access rights to the package. All system administration settings like object permissions, operation permissions, roles, users, distributed licenses must be set up in the production environment directly.
However, you may find this Creatio community post useful if you would like to try to transfer access rights using an SQL script in the package:
Hi Roman. Can you share why it is not 'recommended'?
We have heard different versions from different sources in Creatio. The take away for us has been that - It is 'feasible' to data bind access rights in a package but not 'recommended'.
At the moment, the mechanism for import/export of access rights, the structure of organizational/functional roles cannot be performed using the basic tools, as far as it complex for the architectural implementation. Our R&D team is currently working on its implementation and it will be available in future releases.
About the question of why it is 'notrecommended':
from a development point of view, this business task is complicated, since unique record IDs are created for each system, so that's why we do not recommend transferring access rights by development. And in case you decided to bind this data and transfer to another environment we suggest checking all changes on the copies before delivering it to the prod sites.
I want to bind the access rights of a sectional dashboard. I tried binding the sysdashboard of the particular section and exported the package. I then uploaded the package and found that the access rights of the dashboard to be set to defaults.
Please help me on how to bind the access rights data.