Security Group Setting - Owner/Creator or Products cannot see them

💬 General Discussion
1

Hi
I saw that there was a thread back in 2015 regarding a problem when a user creates a record(s) but then cannot see it/them.

I have a set-up whereby there is company group, with a manager role, who can see all (Group) and a user role, who can only see their own data (Owner). All works fine for the most part.

However, when the user creates a Product, which they need to be able to do, it allows full creation and saves the Product. However, when the user goes into list view of the Products, nothing shows up at all.

In the manager role, they can see the products created fine in list view and individually, so they are there. The only way that the user can get to see them is if the manager does a Mass Update and assigns them to the user. Then they appear as a list and everything works as expected.

I have checked the security group settings and inheritance rules but all seem fine.

Is this still a bug/issue or have I missed a post somewhere ? I have checked in case I have an incorrect setting in my security group and roles configuration, however these seem fine. If I have missed something, apologies, but if anyone has the answer this would be much appreciated.

SuiteCRM 8.2.3
PHP 7.4.33
Msyql 8.0.31 & Apache 2.4

2

Hey
This PR might be helpful for you

3

Many thanks. I will make the code change tomorrow on our test system and if ok, promote it to the production environment.

4

OK. So I made the code changes to SecurityGroup.php and unfortunately, it still does not fix the issue. No log errors of any type, so the code is running and working.

It appears that the products problem is with any user connected to a role with the Owner privilege.

So we have several security groups set up as ’ ****** Procurement’ associated with different product categories. Each group has two role types - manager and support. Users in the manager set can see all information in the Group. Support users see Owner data only, ie anything assigned to them only… This is how the roles are set up.

So one of the support users creates some new product records, which it allows them to do and the info is saved correctly. However, when they look at the list view of products, it is a blank list - ie they cannot see the products that they have just created. We tried refreshing the browser, relogin etc… just to be sure.

Their manager can see all of these new products in list and detail with no problem, as well as products from other support users (who all have the same issue in terms of not being able to see their own created products).

The manager can select products for an individual support user and do a Mass Update to assign the products to that user, who can then see all of the products that they have created.

However, as a process, this can’t work effectively as the support users all need to be able to create products as new product lines are taken on. However, as they can’t see them initially, this is simply not practical.

We have tested all other functions and these work. The only ‘clue’ is that the product creation screen is the only one which doesn’t show an ‘Assigned To’ field with the user ID in it. so whilst the code did appear as though it was going to force this through, when checked in the database itself, the assigned_user_id field for those records created by the users in the support role all contain NULL, so are not being set upon record creation.

So it looks like a bug to us. I have run a quick repair and repair roles in admin, to check if anything had gone out of sync but still the same issue.

Now scratching our heads as the security suite is not something we are keen to mess with. Our only way around this at the moment is to give all of the category support staff Group roles, but they then see a lot of other products in which they have no interest or involvement and need to start filtering everything . If the Owner role worked correctly, none of this would be required.

Any further help would be very welcome, even if it is to tell us that we are doing something wrong, which we can’t see…

Many thanks for the help so far.

5

Sorry, I didn’t read your whole text because I’m in a rush, but - it’s normal in SuiteCRM security to have to assign records to security groups. Not just assign users and roles, but then each record.

The next trick is to make these assignments as automated as possible. SuiteCRM already does that behind the scenes in some occasions, when creating related records etc. This “inheritance” can be controlled to some extent in the Security settings in Admin.

Perhaps all that is missing from your scheme is a couple of these automations to assign groups to records?

6

Many thanks for this. I think you are probably right.

We have tried changing the security group settings using all permutations but none of these change the situation.

When you say ‘automations’ what are you referring to, as I am unclear what you mean.

In SecurityGroup.php, there are comments around line 76 as below.
/**
* Gets the join statement used for returning all rows in a list view that a user has group rights to.
* Make sure any use of this also return records that the user has owner access to.
* (e.g. caller uses getOwnerWhere as well).
*
* NOTE: Make sure to add the check in the where clause for ($table_name.assigned_user_id or securitygroup_join.record_id is not null)
*
* @param string $table_name
* @param string $module
* @param string $user_id
*
* @return string
*/
Which basically gives us a clue that somewhere when the record is created, as the user has ‘Owner’ privileges set in the Role table for Products, it should populate the assigned_user_id field in the database with the user id during the Insert on creation. However it doesn’t, and leaves it as Null. This then prevents the user from seeing what they have just created because the record is not assigned to them as the owner.

The only problem is, I can’t find where this is in the code.

Are we on the right track or is there some setting somewhere in the app that will fix this ?

7

Hi, your pointer set us thinking and we did a very simple change which has fixed the problem.

In Studio, we simply added the ‘Assigned to’ field onto the Product form and did the usual save and deploy.

This brings it up at the bottom of the screen - we added it alongside the Image field, which we don’t use anyway, and it auto fills this on the screen wit the user id, so no user input required at all, and hey presto, in the database, the assigned_user _id is set to the creating user. They can see all of these in their list view and life goes on … :slight_smile:

Many thanks for your input, it just showed us the way when we were looking far too deeply into the root cause.

Tested, checked and deployed to production, so not a bug at all.

1 Like