If I understood your business task correctly, for this purpose you can use the "Access rights setup wizard for Creatio" add-on. Please find more details about the mentioned add-on in the link below:
I have just installed Access rights setup wizard for Creatio.
After selecting some accounts, clicking on "Set up access rights", and choosing permanent (or temporary) righs the system shows "loading" and never returns... Am I missing anything ?
1. Contact the support service to install a package with the [Access rights] business process or install it manually using the [Installed applications] link in the system designer.
I installed via the the [Installed applications] link in the system designer.
2. Record access rights configuration is carried out by clicking the [Actions] button in the section list. To configure access rights:
a. The user who makes the configuration must have the access rights to the [CanManageAdministration] system operation.
b. The user must be a member of the [System Administrators] organizational role.
I am using the Supervisor user, which has the needed access rights.
I had the same issue with this package. I believe it started working after I logged out and back in again (a refresh wasn't enough). I might have also compiled the workspace as well.
I recompiled the workspace, and now I have another problem: I can grant access rights for a selection of accounts (If I open each account individually, I can see that the access was granted). But If I select the same group os accounts (with "Select multiple records" / "Set up access rights" / ") nothing is shown in the "Granted rights"detail, as if the rights were not granted.
To leave the feed message to some role you need to use the feed functionality from the "Feed" section or from the CTI panel feed.
As for mentioning a role in once - there is no such a possibility in the OOB version and our R&D team is working on such a logic implementation. We've informed them about your community question and ask to prioritize the task.
There are many use cases where we need to change the data type of a column. We have observed the following behavior wrt data type changes and want to understand why this happens.
DB - MS SQL
Behavior #1
Say a column has been created as String(250) and published. Changing it to String(50) via the Object designer and re-publishing it does not change the data type at the data base level - even though it reflects correctly in the Package (We also verified that there is no data in the DB which exceeds 50 characters. So technically, it can be downgraded to 50 characters without loss of data). We are forced to alter the column at the database level to actually downgrade it to String(50).
Behavior #2
On the flipside, a data type change from String to Int does work. Additionally, it downgrades the column from NOT NULL to NULLable type in the Database when the String to Int conversion happens.
Can someone string together the above 2 behaviors and why one happens and the other doesn't?
Is there knowledge within the community as to what data type changes work and what do not? If yes, Pls share your experiences.
Note - I am aware that the earlier column can be dropped and a new column with the new data type be created. But this is not practical, if we want to retain the same name.
We tried to reproduce the behavior you have described for different types of DB (PostgreSQL and MSSQL) in two ways:
1. Create a column via Page Designer.
2. Create the column in Object Designer.
At first, we have set the string length 250 for the 1st column, then changed it to 50 in the Object Designer and published the object:
As a result we could see that the data type has been changed from varchar(250) to varchar(50):
Then we have repeated the same actions for another test column (added via Object designer) and result was the same:
That's why it would be really helpful if you could confirm if we were doing the reproducing correctly (maybe we should use another version or another product). Also, we can provide you with a fresh installation files so you can try to re-check it from your side once again (for that just contact our support team via this email: support@creatio.com).
About the second question: in general, we do not recommend to change field types. The system can transfer data type from one char to another when you need to change the length of the field. But it may behave unpredictably when the type is changed from one object to another.
Alos you can find some addtional information about data types in the links below:
Hi Roman, Appreciate your effort in trying to reproduce this.
Your steps does look right -
1. Create as 250 in Object designer. Publish and check if the DB shows nvarchar(250).
2. Change to 50 in Object designer. Publish and check if the DB has changed to nvarchar(50).
I have verified this on 2 Creatio versions - 7.15.2 Studio and 7.16.3 CustomerCenter (Both MS SQL). Is is possible that this got fixed/changed in the latest 7.17 release?? Il also reach out to Creatio support ato replicate this in the latest release.
Hi Roman. Checked this use case once again. The behavior I have stated in my question is correct. I have used a on-premises Creatio sales v7.17 on MSSQL. The datatype does change if you increase the length (Eg 50 to 250) but not from 250 to 50.
Have you checked this on an on-premises or trial instance??
Lets say, I have a Business process which is triggered when an Email Template record is modified, and that Email template is updated via a Package installation, the logical expectation is that the 'Modified' event is triggered and the Business process runs. We however notice that the event is not triggered, and the business process does not run.
Do Package installations and changes through that trigger entity events? Do Package installations effect object changes to the DB via the ORM or does that mechanism work differently?
If I wrote a business process which had a trigger to the SysPackage object and looked for modifications to a specific package, will it get triggered when I install that package??
Our application doesn't support designing business processes that are triggered after modifying system objects. The core of business process mechanisms works on low-level API which doesn't support start signals functionality. This is done in order to avoid any kind of accidents with business process mechanisms and also for performance maintaining reasons.
I am not sure I understood this - "The core of business process mechanisms works on low-level API which doesn't support start signals functionality". Are you saying that the start signal functionality does not work in Business processes?
I binded data from the Lookup table, and now i'm able to see my newly created lookups in the "LOOKUP" section, however, if i click on one of these new lookups, it doesn't open the content, instead an error appears in the browser console saying 'all-combined.js:41 cann't find entity'
This only means that the lookup object wasn't transferred between systems. Please also check if the lookup object was transferred to the target website.
This is a system field that stores the information about processes Creatio can run when a record is edited or deleted. We do not recommend editing it. If you would like to learn more about the way Creatio uses this field, you should review the TryProcessComplete and ProcessCompleteExecuting methods in the BaseEntity object.
This is a system field that stores the information about processes Creatio can run when a record is edited or deleted. We do not recommend editing it. If you would like to learn more about the way Creatio uses this field, you should review the TryProcessComplete and ProcessCompleteExecuting methods in the BaseEntity object.
As was correctly mentioned by Ryan, for this purpose you need to add CSS, where you will be able to configure any colors your business task requires. Additionally to the article which was kindly shared above, the next articles can be helpful as well:
I suggest to investigate the issue in terms of support ticket since it is hard to tell the reason for this behavior. It's better to have a closer look to the website.
I have created a modal with a comboboxedit which contains values from my webservice (attachments from opportunity linked to order). I want to change this into a List instead of a combobox.
In the following images you can see what I'm trying to aim.
Added button to open modal "Migrate Opp Files"
Here's the sample modal with a comboboxedit which shows result of my webservice. I want to change this into a List instead of a combobox.
The value of the dropdown comes from here.
I tried checking the documentation but I'm having a hard time since I'm a visual learner, I learn by seeing how things work in actually through examples.
It seems that it's not possible to add the list to the modal window since the parent entity for the modal window should be "Base entity page" while the list logic was developed in the BaseSectionV2 and related modules as ConfigurationGridGenerator and ConfigurationGrid. I performed a couple of tests and theoretically it's possible to add a list to a modal window, but it requires time to copy all the logic from the BaseSectionV2 and add it to the custom modal window. It's much easier to use a lookup instead.
Kindly suggest a way to lock fields within a detail when we click on Save button of the detail. This should happen without any dependency on other fields within the detail (unlike we usually do based on boolean value true or false).
You could use the CreatedOn field for this. It doesn't get populated until the save button is clicked (not the CreatedBy - it gets populated right away when the page is opened in add mode).
You can create a business rule that makes the field locked if the CreatedOn has a value. Then, the field will be editable when creating a new record, but will be locked as soon as the save button is clicked.
If this route doesn't work, you'll have to use an attribute and code as Oscar mentioned.
Attributes are required to use to lock fields on the page based on some conditions so it's hardly possible to do without any dependency on attributes. Or you can use document.getElementById JS method and change the .style.pointerEvents to 'none'.
You could use the CreatedOn field for this. It doesn't get populated until the save button is clicked (not the CreatedBy - it gets populated right away when the page is opened in add mode).
You can create a business rule that makes the field locked if the CreatedOn has a value. Then, the field will be editable when creating a new record, but will be locked as soon as the save button is clicked.
If this route doesn't work, you'll have to use an attribute and code as Oscar mentioned.
