Hello,

Thank you for your question. 

Please, note that it's not recommended to bind users, organizational structure, roles, licenses, and other administrative things to a package. It will be very hard to handle that if you decide to install that package after the moment when the client adjusts that administrative things according to his or her needs directly on the production.

Unfortunately, there is no script we could provide you with but in case you decide to bind this data and transfer it to another environment we suggest checking all changes on the copies before delivering it to the production websites. The organizational structure is in the "SysAdminUnit" and "SysAdminUnitInRole" tables and you are right, it's possible to bind it to the package via SQL scripts only.

Best regards,

Anastasiia

We usualy do the following:



Create separate package for Roles

1. Add Data for SysAdminUnit 

2. Add Data for SysUserInRole



Before you install the package

Switch off trigger TRSysAdminUnitRoot in table SysAdminUnit (otherwise it will block adding new roles)



Install the package

Switch on trigger TRSysAdminUnitRoot in table SysAdminUnit



And always remember, that deleting of data cannot be transfered without SQL script

Hello Julio,

The responsible team is working to fix this. The error appears due to the changes in the basic functionality in version 7.18.3. We plan to publish the updated package no later than the end of October.

Alexander Demidov,

Thank you very much @Alexander! :-)

Best regards

Hi Anupama,

DataStreamError can be a result of a connection loss between the app and repository and as a result not all the changes are being transferred. Can you please specify what happens if you export the package from the dev-app and import it to the target app using standard package export\import?

Best regards,

Oscar

Oscar Dylan,

Yes, even when we do standard Package import, receiving the data stream error. Basically in two scenarios we are experiencing this:

1. While updating package from SourceTree 

2. While installing a plugin

Anupama,

Please provide us with the detailed step-by-step instruction on how can we reproduce the same issue in the local app and we will check it.

Best regards,

Oscar

 Oscar Dylan,

It is reproducible in two scenarios:

1. When we deploy and update package in a new instance/environment-
   1. we use Git and SourceTree for source control.  when we clone the repository and update the package, we get the attached error<StreamError.jpg>.
2. While installing any marketplace plugin in existing instance
   1. installation fails and in the error log the same error message is captured

      <<uploaded the error logs in the main section>>

Hi Fulgen!



Thank you for your question!



In this case, we would recommend you binding the data with the packages. You may read more on how to bind the data here (the link is clickable) and here (the link is clickable).



Please note that the schemas you ought to bind are: SysSchema & SysWorkplace with your package.

Hope this helps.

In case you have any other questions, please, feel free to contact us!



Ivanna.

 

Ivanna Yatsura,

Please, can you explain why we need to bind SysSchema? 

Jahnavi,



Data binding is a process that ensures the developed functionality is transferred correctly between environments. When you bind SysSchema, you are essentially ensuring that the schema (the structure of your data) is correctly transferred and maintained in the new environment



Regards,

Orkhan

Hello!

Unfortunately, there is no basic way to import/export access rights from the system since it is a complicated mechanism and it cannot be extracted from the system easily. You can use custom SQL scripts in the package in order to transfer such information. Below you can find tables that store information about access rights:

1. Sys[SectionName]Rights
2. SysEntitySchemaColumnRight
3. SysEntitySchemaOperationRight

Since it is a complicated task we suggest using the Marketplace application which can ease access rights setup: https://marketplace.creatio.com/app/access-rights-setup-wizard-creatio

Please, let us know in case any further assistance is required. 

Best regards,

Olga. 

Dear Harvey, 



Theoretically, it's possible. 

However, we recommend you to contact Creatio support team and request a DB backup of your website if it's deployed in cloud and carefully test it on the copy of the website before making any changes to actual production. 



Kind regards,

Roman

Hi Roman, is there a better/recommended way to reset all users' column bindings back to the defaults in an environment?  Also, what are the risks involved around doing this? I understand that users' applied filters for each Section are also stored in this table - what other data is stored there which could cause a problem if it were deleted?

Thanks

Any changes on this/better way of resetting all default list settings for users since this was posted? This is a frequent need.

Hi Tomek,

Can you please provide us with more details on the data that you are creating? How do you do this, please provide us with steps to reproduce the message? In which package do you try to save the data? Can you please provide us with the screenshot of the error?

Best regards,

Oscar

Oscar Dylan,

Thanks Oskar 

I think i found the problem.

I use lookup reference in Data and main table was not transfer by data as well.

So thing thats a problem.

I transfer the data by script by codes.

thanks for help

Regasrds

Tomek

Dear Robert,

Organization Roles can be transferred only by SQL scripts. Functional roles are transferred by binding data of the System administration object. The rights to existing records should be transferred via scripts as well. To distribute rights to new records you can either set up a business process or configure object permission directly on the production environment.

Best regards,

Angela

Angela Reyes writes:

Dear Robert,

Organization Roles can be transferred only by SQL scripts. Functional roles are transferred by binding data of the System administration object. The rights to existing records should be transferred via scripts as well. To distribute rights to new records you can either set up a business process or configure object permission directly on the production environment.

Best regards,

Angela

Thanks Angela!

But the question is how can I transfer the definition of the permissions, without rewriting the SQL script over and over again?

Is the following procedure the only way?

1. Select the current permissions manually with SQL
   
   the tables are:
   1. SysEntitySchemaOperationRight for object permissions
   2. SysEntitySchemaRecordDefRight for record permissions
   3. SysEntitySchemaColumnRight for column permissions
2. transform the result to and insert/update statement
3. save those scripts in the package SQL section
4. export/import package

And do I have to/am I allowed to truncate those 3 tables first?

Is there a stored procedure that applies the new permissions on the target systems' records?

Thanks a lot and best regards

Robert Pordes,

Your description is almost correct. Please see all steps:

1. Create scrip for update/ insert records from SysAdminUnit table to use these records in the next steps

2. Select the current permissions manually from SQL the tables:

2.1 SysEntitySchemaOperationRight for object permissions

2.2 SysEntitySchemaRecordDefRight for record permissions

2.3 SysEntitySchemaColumnRight for column permissions

2.4 Also there are tables like Sys{ObjectName}Right (e.g. SysAccountRight) in which record rights are stored, so you should create script for each object. 

3. Transform the result to and insert/update statement

4. save those scripts in the package SQL section

5. export/import package

Best regards,

Angela

Hi Angela,

thanks, but aren't the tables Sys{ObjectName}Right storing the applied rights (they will be populated by clicking "update record permissions", correct?). If I create scripts on eg DEV system, the data will not be the same! I mean we will definitely have different eg. account and contact records on dev/test/prod system.

That's exactly why I asked this in my previous post: 

Is there a stored procedure that applies the new permissions on the target systems' records?

Thanks,

Robert

Robert Pordes,

There is no stored procedure. This is why I suggested workarounds like

binding data and business processes.

Best regards,

Angela

Hi Harvey,

I have also faced the same issue and as far as I know, this does lead to problems.

We therefore only use the data-binding tool to make the creation of the bindings easier. When changing bound data, we go to the data tab in the package and open and save it to update its contents. 

Renaming the created data bindings to something more meaningful than the GUID also helps to identify them again.

Hope this helps!

Bes regards,

Robert

Hello Harvey,

You can check duplicates after saving a data binding. When the "Data was bound successfully" message pops up, click "View details" and save the data binding once again. If the binding holds any duplicates, a standard validation page opens.

I have forwarded your suggestion regarding the check for duplicates to the responsible developer team.

Thanks for the reply Andre, that sounds like a useful best-practice to follow when using the tool then. It would be very helpful if the tool itself were able to pass on such errors automatically, but I can see that programmatically checking whether data has been bound twice would be quite difficult! It would be a real benefit to the tool if it could be done, however.

Hello Harvey,

Creatio developers are currently migrating the basic data binding functionality to the new UI. The team responsible for the "Data binding tool" add-on will consider possible functionality improvements after the release of Creatio version 7.17. Due to UI framework migration, any new improvements that they make right now can be rendered obsolete in the new release.

Thank you!