We are running out of space for buttons in the usual places. We have removed the icons in the communications panel at the top of the Actions Dashboard (see this article). Is there any way to add buttons back in?
I have tried adding a button setting 'parentName' to "CaseSectionActionsDashboardMainContainerContainer" without success.
Please clarify your task: do you need to return the buttons that were removed from the Actions Dashboard or do you need to add some new buttons there? Maybe you could share some image of what it should look like?
We need to add some new buttons. We have removed the facebook, telegram, message and other buttons (which are actually tabs I think) from the Actions Dashboard, is it at all possible though to put a 'Terrasoft.ViewItemType.BUTTON' in their place?
It's not possible exactly in the tabs (you are right, Email, Call, Activity etc. on the actions dashobard are tabs), but there are elements like ActualDcmSchemaInformationButton button and PlaybookButton button that are inserted to the RightHeaderActionContainer element of the SectionActionsDashboard and you can use those as an example. Additionally to it, if you ran out of space on the page you can always add additional buttons to the "Actions" button (override the getActions method on the edit page schema) and call the logic needed from these buttons.
We would need to conduct a deeper analysis of the issue to provide you with a solution. Please write to us at support@creatio.com so we could help you.
Is there a system table that can be queried to find out which section and/or detail run process menu(s) a process is found in? Or any other way of doing this?
*Edit* A query to find out what section(s) an object is a detail in would be quite helpful.
Also, there is no differentiation in Creatio between section and detail objects. So basically, an object is the same for a detail and a section. You could use the following script:
SELECT DISTINCT ss.Name ,
CASE
WHEN EXISTS (SELECT 1 FROM SysModule WHERE SysModuleEntityId IN (SELECT Id FROM SysModuleEntity WHERE SysEntitySchemaUId = ss.Uid)) THEN 'Section'
WHEN EXISTS (SELECT 1 FROM SysDetail WHERE EntitySchemaUId = ss.Uid) THEN 'Detail'else''
END AS "Section/Detail"
FROM SysSchema ss
WHERE EXISTS SELECT 1 FROM SysModule WHERE SysModuleEntityId IN (SELECT Id FROM SysModuleEntity WHERE SysEntitySchemaUId = ss.Uid)
OR EXISTS
(SELECT 1 FROM SysDetail WHERE EntitySchemaUId = ss.Uid)
AND
ss.ManagerName='EntitySchemaManager'
*Edit* The below queries return both active and inactive processes., at a glance I am not able see how to select active only.
The query we arrived at to list the processes in the run process menu of sections:
SELECT SM.Caption AS [Section Name], SS.Caption AS [Process Name]
FROM ProcessInModules AS PIM
JOIN SysModule AS SM ON PIM.SysModuleId= SM.Id
JOIN SysSchema AS SS ON PIM.SysSchemaUId= SS.UId;
And the query to list the processes in the run process menu of individual details:
SELECT SD.Caption AS [Detail Name], SS.Caption AS [Process Name]
FROM ProcessInDetails AS PID
JOIN SysDetail AS SD ON PID.SysDetailId= SD.Id
JOIN SysSchema AS SS ON PID.SysSchemaUId= SS.UId;
I would like to be able to say what sections a detail appears in, but would imagine this information to be buried deep in Creatio system tables.
If anyone can check the above queries I would be grateful!
The queries you have written are correct. However, it's hard to check which details belong to which sections by a DB query as details are connected to a page in the page's schema. So you need to decode the schema's content and filter in it. Such a query is hard to build and it will take a long time for it to get executed.
First of all please keep in mind that access rights might be inherited and since your custom section is based on Contact lookup - permissions are checked for Contacts as well as for your Custom section.
We also recommend looking at the SysSSPEntitySchemaAccessList table. There should be a record of the schema with which you have a problem. For portal users, by default, all schemas are considered to be administered and inaccessible. In order that portal users can use them, this schema must be in the lookup (the list of objects available to portal users). In other words - it must be in the SysSSPEntitySchemaAccessList table. After adding this schema to this table, the problem should be solved.
Should the above trouble-shooting not resolve your issue - please send us an email with detailed explanations of your problem to support@creatio.com so we may inspect and analyze your specific case (as it is too few details available by now and further evaluation will be required for precise solution)
Is there any way I can access a button instance directly, e.g., in the 'click' method of a client module in order to set the colour of the button using the setStyle method of the button object?
Not sure if it's possible since setStyle only receives some value as an argument and is being executed when the button is initialized.
In your case I would recommend to add this code to the click handler:
var buttonElementToModify = document.getElementById("ContactPageV2ChangeContainerStateButtonButton-textEl");
buttonElementToModify.style.backgroundColor="Green";
and replace ContactPageV2ChangeContainerStateButtonButton-textEl with an actual id of the element in DOM:
As a result when the button is clicked its color will be changed to green.
This element will generate the code itself and you don't need to change the Schema manually, which will be much complicated and could potentially affect the whole page.
We have a business use-case like enabling the MiniPage (View Mode) in the activity section based on conditions. I have enabled the view mode of the MiniPage, now I am able to see the mini page for all the records. But I need to show it for the records based on some conditions like (Eg: Title = "Appointment").
The logic below will make a mini page in view mode not appear on the page in case the title of the activity contains the "Visit" word.
Create a replacing view model for the ActivitySectionV2 and add the following code there:
define("ActivitySectionV2", [],
function(){return{
entitySchemaName:"Activity",
attributes:{"ResultGridSet":{"dataValueType":this.Terrasoft.DataValueType.TEXT,
"type":this.Terrasoft.ViewModelColumnType.VIRTUAL_COLUMN,
"value":""}},
mixins:{},
methods:{
onGridDataLoaded: function(response){this.callParent(arguments);
var subjectsToExclude ="";
Terrasoft.each(response.collection.getItems(),function(item){
var activityTitle = item.values.Title;
var activityId = item.values.Id;if(activityTitle.indexOf("Visit")!=-1){
subjectsToExclude = subjectsToExclude + activityId +",";}});
subjectsToExclude = subjectsToExclude.substring(0, subjectsToExclude.length-1);this.set("ResultGridSet", subjectsToExclude);},
prepareMiniPageOpenParameters: function(options, entityInfo){
var rowId = options.rowId;
var gridSet =this.get("ResultGridSet");if(gridSet.indexOf(rowId)!=-1){return;}this.callParent(arguments);}},
diff:/**SCHEMA_DIFF*/[]/**SCHEMA_DIFF*/};});
The logic is simple:
1) onGridDataLoaded method is always called when the grid is loaded in the section. It contains the response argument which contains actual data that is stored in the grid (and we can use it).
2) Once onGridDataLoaded is called we take the response and check if the activity title contains the "Visit" word and perform this check for each item in the grid. If the activity title contains the "Visit" word we take an Id value for this activity and add it to the string subjectsToExclude parameter.
3) subjectsToExclude parameter result will be then passed to the ResultGridSet attribute that will be then used inside the prepareMiniPageOpenParameters method.
4) prepareMiniPageOpenParameters method is the method from base MiniPageUtilities mixin and we need to override its logic in the Activities section. prepareMiniPageOpenParameters has the options argument that is primary data regarding the activity on which the mouseover event was called. We can get the activity id from the options argument and use it further.
5) Inside the prepareMiniPageOpenParameters method we get the ResultGridSet attribute value and then check if the Id that was received from options can be found inside the ResultGridSet string. If it can be found the prepareMiniPageOpenParameters does nothing (and as a result the minipage is not opened), else - perform the parent method execution.
Feel free to create your own logic based on this example.
The logic below will make a mini page in view mode not appear on the page in case the title of the activity contains the "Visit" word.
Create a replacing view model for the ActivitySectionV2 and add the following code there:
define("ActivitySectionV2", [],
function(){return{
entitySchemaName:"Activity",
attributes:{"ResultGridSet":{"dataValueType":this.Terrasoft.DataValueType.TEXT,
"type":this.Terrasoft.ViewModelColumnType.VIRTUAL_COLUMN,
"value":""}},
mixins:{},
methods:{
onGridDataLoaded: function(response){this.callParent(arguments);
var subjectsToExclude ="";
Terrasoft.each(response.collection.getItems(),function(item){
var activityTitle = item.values.Title;
var activityId = item.values.Id;if(activityTitle.indexOf("Visit")!=-1){
subjectsToExclude = subjectsToExclude + activityId +",";}});
subjectsToExclude = subjectsToExclude.substring(0, subjectsToExclude.length-1);this.set("ResultGridSet", subjectsToExclude);},
prepareMiniPageOpenParameters: function(options, entityInfo){
var rowId = options.rowId;
var gridSet =this.get("ResultGridSet");if(gridSet.indexOf(rowId)!=-1){return;}this.callParent(arguments);}},
diff:/**SCHEMA_DIFF*/[]/**SCHEMA_DIFF*/};});
The logic is simple:
1) onGridDataLoaded method is always called when the grid is loaded in the section. It contains the response argument which contains actual data that is stored in the grid (and we can use it).
2) Once onGridDataLoaded is called we take the response and check if the activity title contains the "Visit" word and perform this check for each item in the grid. If the activity title contains the "Visit" word we take an Id value for this activity and add it to the string subjectsToExclude parameter.
3) subjectsToExclude parameter result will be then passed to the ResultGridSet attribute that will be then used inside the prepareMiniPageOpenParameters method.
4) prepareMiniPageOpenParameters method is the method from base MiniPageUtilities mixin and we need to override its logic in the Activities section. prepareMiniPageOpenParameters has the options argument that is primary data regarding the activity on which the mouseover event was called. We can get the activity id from the options argument and use it further.
5) Inside the prepareMiniPageOpenParameters method we get the ResultGridSet attribute value and then check if the Id that was received from options can be found inside the ResultGridSet string. If it can be found the prepareMiniPageOpenParameters does nothing (and as a result the minipage is not opened), else - perform the parent method execution.
Feel free to create your own logic based on this example.
It is interesting. Might be it behaves differently in different sections. But I see your screenshot, you have debugged in the ActivitySection right. I have implemented the functionality on the same schema page. It seems to be weird behaving different across instances!
I have an "Anúncios" lookup. I want to create a new record from the lookup, but in the "Anúncios" lookup, the record is created but the relationship is not.
Unfortunately, it can't be configured automatically.
So, after creating a new record from the lookup you have to configure the relationship manually,
As a workaround, you can create a new business process to achieve your business task,
We have already registered the idea for our R&D team to implement this functionality in further releases. I will assign your case to this project in order to increase its priority.
