Good day, colleagues.

 

When attempting to create a record in a related object using User-Task, I receive the error "Insufficient permissions to add record in object 'SomeObject'." Current permissions for this user in "SomeObject" are set to Read-only. However, when using the classes new EntitySchemaQuery(), new Entity(), and userConnection.EntitySchemaManager.GetInstanceByName("Entity_Name"), I set the UseAdminRights property to true.

 

I have used three different approaches:

 

1.
new SomeEntity(_userConnection)
{
   UseAdminRights = true
}

 

2.
new EntitySchemaQuery()
{
  UseAdminRights = true
}

 

3.
EntitySchema instanceByName = _uc.EntitySchemaManager.GetInstanceByName(typeof(EntityType).Name);
instanceByName.UseDenyRecordRights = true;

 

None of these have successfully created or retrieved the record. I request assistance in figuring out how to forcibly disable permission checks for any CRUD operations on the backend.

Like 0

Like

5 comments

Hi,

 

Example from the OmnichannelContactIdentifier (OmnichannelMessaging package):

 

var esq = new EntitySchemaQuery(UserConnection.EntitySchemaManager, "ContactIdentity") {
                UseAdminRights = false
            };
            esq.PrimaryQueryColumn.IsAlwaysSelect = true;
            esq.AddColumn("Contact");
            esq.AddColumn("Channel");

...

Please try this approach of specifying the UseAdminRights flag for the server esq.

In addition to Oleg's response, you can also use the Select, Insert, Update, etc classes, they bypass security since they are executing direct in the database. See https://academy.creatio.com/docs/8.x/dev/development-on-creatio-platform/8.1/direct-access-references

Also, you can get the SystemUserConnection to use for the ESQ.

Also worth noting for people who haven't used the Select, Insert, Update etc classes, they bypass all Creatio application logic, so things like Business Process triggers on record creation or update too. They are very useful, but need to be aware of that to avoid issues.

One more detail, if it isn't clear by now: the UseAdminRights flag doesn't mean "use the permissions of the administrator"...actually, the opposite is the case. It means "enable the usage of permissions".
I find the wording pretty misleading, but that's how it is ;)

Yes, naming leads to opposite meaning

Thx a lot for answers

Show all comments

Hello,

 

I would like to know how to approach the task of extracting the model of field entities to a CSV  or Excel file.

The idea is to provide project managers with a simplified view of the fields available in my Creatio instance. I'm not looking for details, just the field name, code, label (translation?), data type.

 

Any sugestions on how to approach this task?

 

Thanks,

Vlad 

Like 0

Like

4 comments
Best reply

This marketplace addon will provide you with an Excel export of all obejcts in the system, along with columns, data types, display titles of objects and columns, etc. 

https://marketplace.creatio.com/app/object-structure-export-creatio

Once installed, there will be a process you can run that gives you the Excel file. 

Ryan

Hello!

 

You can check all the information about data export on Creatio Academy:
https://academy.creatio.com/docs/8.x/creatio-apps/creatio-basics/business-data/exporting-list-data-to-excel

Thank you for your reply Arsenii, but it is not the data that I am trying to export, but the model.

 

Exemple for Accounts entity:

 

field name; field code; field label; data type; default value

Name; Name; The company name; Text - 250 caracters; <empty>

Phone; Phone; Main phone number; Text - Phone number; <empty>

Web; Web; Compny Website; Text - Web link; <empty>

(...)

 

Kind regards,

Vlad

 

This marketplace addon will provide you with an Excel export of all obejcts in the system, along with columns, data types, display titles of objects and columns, etc. 

https://marketplace.creatio.com/app/object-structure-export-creatio

Once installed, there will be a process you can run that gives you the Excel file. 

Ryan

Ryan Farley,

Perfect, I'll give it a try. 

 

Thank you,

Vlad

Show all comments

We really need some disambiguation of what changing options in Page Designer do around whether this is a page-only change, or will actually end up modifying the underlying object that the page is based on as well. This can have knock on effects that people don't expect, when they may believe they are changing something that should only be affecting the page they're working on.

 

For example, changing the "Title" property shown on the Page Designer will change the underlying entity's field's Title, while the "Lookup view" just below it seems to only change the lookup mode of the field on that page (while there is a "Lookup view" property of the field on the entity, at least when I just tested it, it didn't change). This leads to confusion and caution around changing things to avoid having unexpected impacts, or even worse to unintended consequences slipping through the net.

0 comments
Show all comments

Is it possible to create an entity based on a view (so with the "Represents Structure of Database View" checkbox checked, and with the view created using a SQL script) that inherits its record permissions from a "real" entity? I tried to do so by simply checking the record permissions checkbox and specifying the parent object in the "Object to inherit access permissions from" field of the entity, but this doesn't seem to work.

 

My setup is that we have the OOTB Leads entity, and then I've created a view over the top of it taking all columns but with a filter condition, to be used for reporting over Leads while filtering out certain Leads that should never be included in reporting so we have a more consistent reporting basis and don't have to make sure to include those filters in every widget. I added 2 columns to the view based on the Id and LeadName columns called UsrBaseLeadId and UsrBaseLeadName, which then have a lookup column UsrBaseLead added over them in the view-based entity. This lookup is then used as the "Object to inherit access permissions from" for the view-based entity.

 

There aren't any errors thrown in the logs when trying to do this, but non-super-users just can't see any of the records. When I tried to check a record in the view's permissions, I could see that the SysRights table for the view entity doesn't exist, so I tried creating that rights "table" as a view in the database that took its data from the Rights Table of the real entity, but while that seemed to work inasmuch as I could check a record's access rights and see that the correct rights were there and was even able to modify those rights, it didn't make it visible to a non-super-user.

Like 1

Like

3 comments
Best reply

It would be great to have the view be able to inherit permissions from some object that the view has as a lookup column. However, I don't believe that is possible. What I typically do is this:

  1. Create a view and include as a column some other object that has permissions (for example, if the view includes an Opportunity lookup column and the account has permissions)
  2. Anywhere the view is used, include a filter condition that some column on that related object is not null (that would never be null). Plus it cannot be the Id or the column used as the display value. Example, if my view has a lookup for Opportunity, I could use Opportunity.Stage is filled in.
  3. Using this approach, the user will only see the rows corresponding to the related record that they have access to, since if they cannot view the related opp the Stage will return a null value. 

It's not ideal and definitely not secure, but it does limit the view rows to what the user can see on the related object.

Ryan

Anybody have any experience of working with such a setup?

It would be great to have the view be able to inherit permissions from some object that the view has as a lookup column. However, I don't believe that is possible. What I typically do is this:

  1. Create a view and include as a column some other object that has permissions (for example, if the view includes an Opportunity lookup column and the account has permissions)
  2. Anywhere the view is used, include a filter condition that some column on that related object is not null (that would never be null). Plus it cannot be the Id or the column used as the display value. Example, if my view has a lookup for Opportunity, I could use Opportunity.Stage is filled in.
  3. Using this approach, the user will only see the rows corresponding to the related record that they have access to, since if they cannot view the related opp the Stage will return a null value. 

It's not ideal and definitely not secure, but it does limit the view rows to what the user can see on the related object.

Ryan

Yeah that's a clever workaround, many thanks Ryan! Agreed about the security aspect, but for the the cases where it's just about having those record permissions used to define non-security visibility as I currently have for the base entity it will work for now.

 

It would definitely be good for the view entities to be able to inherit permissions from lookup columns though, and feels like it would be a relatively quick win for Creatio to add, as most of the functionality around that would already exist. It could even be done in a no-code way by enabling the creation of these view-based entities directly in the config, effectively adding a logical layer to the platform which would be great for filtered views into the data and adding virtual calculated fields. So much utility to be had with such a logical layer.

Show all comments

In the spirit of minimising code/making more of the config declarative rather than telling the system exactly how it should be doing things step by step, it would be very useful to be able to have calculated fields on entities in Creatio. Currently this needs to be done in business processes, which means creating the field in one place, creating the calculation somewhere else, and maintaining the conditions for firing of updates manually. It would be much better if we could have OOTB calculated fields much like many other CRM offerings on the market.

 

It would reduce issues around data not being updated at the right time, or changes in one place breaking config in others, and reduces processing time/disk IO spent on running business processes that have to read, modify and write data in addition to the data originally being written to disk - essentially duplicating the work the servers are having to do for each record. It can also centralise business logic into one place, rather than having different areas of code/config doing the calculation themselves and potentially becoming misaligned.

 

Ideally it would be able to incorporate data from other entities, including the ability to aggregate, but honestly just being able to have calculated fields based entirely on data on the same entity would be a big improvement.

1 comments

+1

Show all comments

Hello Community!

 

I'm trying to fill a field with the result of a simple calculation (e.g. field A - field B).

 

However, when I create the business rule and select "set field" as action, I can only provide a constant value and not a formula...am I missing something?

 

Here is a screenshot of the 

 

I know that I can use a business process to achieve this, but this would be much more simpler and elegant I think.

 

BR,

Robert

Like 0

Like

4 comments
Best reply

It's not yet available in Freedom UI --> Creatio Roadmap indicates for Q4 2023 https://academy.creatio.com/docs/release/creatio-roadmap?check_logged_i…

I forgot to add that I use version 8.0.10.4735

It's not yet available in Freedom UI --> Creatio Roadmap indicates for Q4 2023 https://academy.creatio.com/docs/release/creatio-roadmap?check_logged_i…

Damien Collot,

Thanks Damien, at least I know that I did overlook something.

Hi Damien,

I do not have access to the link to the roadmap.

I get this message:

"

Access denied

You are not authorized to access this page.

"

Is it restricted?

It is very interesting information.

Thanks,

Luis

Show all comments

Hello Community,

Is there any way in Creatio to read all Entity fields from front-end (including lookups),besides fetching the entity Metadata?

Thank you

Like 0

Like

3 comments

Hello Petrika,

 

Can you please share a screenshot or a detailed description of your business task?

 

Thank you!

 

Best regards,

Oscar

Oscar Dylan,

In this case I want that in the Lookup, all the fields (Display Value, not the name of the fields in the database) regarding the application form are displayed. How is this realised Oscar ?

Thanks very much !

Petrika,

 

Now I understood, thank you!

 

You will need to preform the SelectQuery request directly to the database from the client-side using filtration needed (this is what happens if you click the lookup, just check it in the "Network" tab of the console) or you can perform the ESQ query to get data from the lookup drop-down. Using one of the scenarios above you will be able to get data needed.

 

Best regards,

Oscar

Show all comments

Hi all,

    I try to use class Entity to save data, here is my code:

DsslmContractActivityLogData logData = new DsslmContractActivityLogData(UserConnection);

                logData.DsslmLogId = logId;

                logData.DsslmSchemaPrimaryKeyValue = item.SchemaPrimaryKey;

                logData.DsslmSchemaName = item.SchemaName;

                logData.DsslmSchemaJsonData = item.JsonData;

                if (!logData.InsertToDB())

                {

                    this.Logger.Info("Create log failed");

                }

The result is always false without any error message. What happen?

Like 0

Like

1 comments

Dear Toan,

 

Unfortunately, it is difficult to determine the root cause of the issue without debugging the source code. Please try to use the “Insert” class instead of the current approach. Please find more information about this class in the article by the link below:

 

https://academy.creatio.com/documents/technic-sdk/7-16/insert-class

 

Best regards,

Norton

Show all comments