Hi, yes, there is a way to set it up. The necessary information you will find in this article: https://academy.creatio.com/docs/user/setup_and_administration/user_and…

Hi Bao,



I think, such filter can do this

Kind regards,

Vladimir

Vladimir Sokolov,

Hi Vladimir,

That's a great idea! We tried and seems okay for now!

But, I have a further question.

As my try, a team member from Country 1 team could able to see the folder used for Country 2 Sales Team when they use the filter function. We want to separate the view of both teams and don't allow Country 1 team could see any record from Country 2 team

So, How can I able to do that?

Bao Phan,

Here you need to write Process that changes access right to record when record is added and Owner or Team are changed 

https://academy.creatio.com/docs/user/bpm_tools/process_elements_refere…

Thank you, Vladimir Sokolov

Sorry for my late reply

I didn't get any notification about the reply

But thank you!

Dear Moheman, 



Unfortunately, it's hard to say what have caused this behavior on the website. 

Please contact our support team via an email support@creatio.com and provide us with more details on what actions were made on the website prior to that so we could check it. 



Kind regards,

Roman

Hello Markus,

You can write your own EventListeren on onDeletnig event and if your condition is satisfied, you can call base.OnDeleting(sender, e).

If not, it will block the delete action no matter who is the user.

public override void OnDeleting(object sender, EntityBeforeEventArgs e) {
				var entityOrderProduct = (Entity)sender;
            	var OrderProductid = entityOrderProduct.PrimaryColumnValue;
				string name = entityOrderProduct.GetTypedColumnValue<string>("Name");
				if (name != 'someting'){
					base.OnDeleting(sender, e);
				}
			}

Hello,

Please check the permission settings in the Object Permissions section.

 

Perhaps the manager role does not have permission to view records in the Accounts section

Hello,

As we mentioned in the submitted case to support, we do not recommend you manually check those boxes, to properly add them please follow the steps below:

1. In the object, permissions section add your restrictions
2. The system will create a "copy" of the object you are working on in the current package as a reference to the original object
3. In that copy, you will see the checkboxes checked for the chosen options from object permissions.

Please make sure to set the "Current Package" system setting to the one you are developing in.

For further questions please refer to your support case.

Thank you.

Hello Jonathan,

Could you please specify the version of your application?

Thank you!

Best regards,

Bogdan S.

Hi Bogdan Spasibov,

The actual version of Creatio, 7.18.3.

Hello Jonathan,

The "Deny reading and editing" option won't hide the field but it can hide the value of the field. For example, with the following setup, all company employees will see the field value except for the users that are added to the '1-st line support' role:

But the best way to achieve you business task is to use business rules. There is a rule that is called 'Show an element on page'. It allows you to show the specific field on the page only for some users. For example, with this setup only Supervisor can see the 'Budget' field on the page:

Please note that as of now the business rules can be applied to users only. The setup with org.roles should be available in one of the upcoming releases.

Best regards,

Bogdan S.

Hi Bogdan Spasibov,

Thanks a lot for your answer. The first methods doesn't seem to work. I created an opportunity, set the "Budget" field to 3'500. Then went to the object permissions and set "Deny reading and editing" to the "Direction" Organizational role. When I log in with a "Direction" user, I can still se the 3'500.

However, your second solution helps me a lot and is perfect for what I want to do. 

Thanks :) 

Jonathan Quendoz,

Hi,

please be careful with using business rules as a means for data access restrictions! They only work on the page where they are configured! So this will not if the user adds the field to the opportunity list.

Besides this, I think that the order in Bogdans answer should be the other way round. Permissions are evaluated by priority and the first hit will count. Since every user is in the "All Employees" group, the second row will never be evaluated.

BR,

Robert

Hi Malay,

So what seems to be the issue? The process doesn't remove the rights from activity or doesn't assign them to the required employee?

Thanks.

Dean

dean parrett,

Thanks for the reply.

Yes, It is not working as it should. Right now, all employees can see and edit the records assigned to other employees.

Thanks,

Malay

Hi Malay,

I suggest you to approach the support team. It is necessary to look through the all rights settings as well as the process. You will get the solution faster in this case.

Regards,

Dean

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