Gridview - Hide columns


(Chai Chang) #1

Trying to see if there’s a way to hide a particular column in a gridview. I know that you can go into personalization and hide it. However, there are some sensitive data that we want to move from the gridview completely and not allow the user ability to change it through personalization. Probably possible via code, but I haven’t done it before. Someone have an example they can provide?

(Jose C Gomez) #2

You can just set the field security…

(Sergiu Udrea) #3

How this “set the field security” can be done ?

(Jose C Gomez) #4


(Sergiu Udrea) #5

This seems to work for the fields at the database table level (columns from the datatable), and probably will affect this field in all forms and dashboards where is present.
He asked to “hide a particular column in a gridview”, I think this can be done if you uncheck the Visible property in the dashboard and then you deploy it, so like this will not be visible for anyone ?

(Chai Chang) #6

I can take a look at Field Security if we can have groups that are allowed to see it and most are not allowed. It’s the job tracker, it’s got the labor hours and labor cost. People might be able to take the 2 and calculate someone’s labor rate with that information. So I just want to hide the labor cost from job tracker for now since it is available to a lot of people.

(Brandon Anderson) #7

Our company has chosen to apply an averaged labor rate for this reason and others. The labor rate for the employee and the actual pay rate do not need to be the same.

(Chai Chang) #8

Yes, for us, they decided to use actual labor rate. This labor cost looks like it’s a calculated cost using (LaborHrs*LaborRate). So maybe a field security may not work? I can try just putting a security on the “LaborRate” field and see.

(Chai Chang) #9

Field security maintenance doesn’t work since this is a calculated field. I tried to go to the job tracker and customized it by hiding the column from gridview. However, users can still go into personalization and unhide the column.

I tried searching to see if anyone has attempted to remove any column from a gridview, but doesn’t seem like it. Anyone has done this before and can provide some insight?

(Jose C Gomez) #10

Since its just Job Tracker you could also use a BPM to change the data in those fields after getByID to set them to 0

(Chai Chang) #11

Ah never thought of that. Thank you. I will try the BPM and change the field after getByID to 0.

Anyways, I did look at the Field Security maintenance for other field security access. It doesn’t seem to be working with my testing. We are on

Below is what I did:

  1. Open Field Security Maintenance.
  2. Schema is ERP
  3. Table select ProjectCst
  4. Select the field, in this case it’s TotActLbrCost
  5. From Detail tab change the “Default Access” to None.
  6. Check “All Companies”.
  7. From Users/Groups select the group and select default to “None”.

Once that’s done, I create a test user and assigned the user to that group that is supposed to have no access to TotActLbrCost. Signed out and in as that user. I can still see the TotActLbrCost.

So not sure if Field Security Maintenance works in this version or I am not doing something right.

(Brandon Anderson) #12

I think you have the wrong table. That’s for projects.

I think this is the one you want.

(Chai Chang) #13

Actually, I am now looking at project cost as well since we also have projects with Time&Materials and want to remove the TotActLbrCost from Project Entry.

However, what you provided might help. I can try that route and see if it’ll prevent users from being able to see the “Labor Cost”. Just not sure if Field Security Maintenance is actually working or not. I tried a few other fields, and I can still see it with my test user.

(Richard Riley) #14

Is your test user a Security Manager? Security is not applied to Security Manager users.

(Kevin Simon) #15

This is a bit complicated, but it’s a solution… I had a client from a number of years ago (8.03 perhaps) that wanted a lot of fields hidden from job tracker. The concern was exactly what you have, they didn’t want users to be able to personalize screens and unhide the fields. I don’t recall the specifics, but we didn’t want to use field security either (probably because it’s not been the most reliable).

What I did was I created a security group for people who COULD see the data. Then, on the methods that returned the data (such as “GetRows”), I had a post-processing BPM that read the user security, and if they were NOT in the “special” group, I moved zeroes to the “tt” fields we didn’t want them to see. So, whether it was in a grid view, a detail view, they personalized - whatever - all they could see was 0 in those fields anyway.

The hardest part was identifying which programs the unwashed masses could use and identify which methods we needed to add this to.

Kevin Simon

(Chai Chang) #16

I created a test user that have very limited access and that user can still see it. The user is not security manager.

I did take a look at the BPM solution and still playing with it. Will post if I do run into issue and need some guidance. Thanks.

(Chai Chang) #17

So I want to set the highlighted to zero. The EpiBinding is DocActTotLbrCost.

I did a Post Method Directive for GetByID, and set the field to more than 0. However, I am putting a message just to have it pop up if the condition DocActTotLbrCost is more than 0. It doesn’t seem to be doing anything. Anyone see anything I missed?

(Brandon Anderson) #18

Does it fire when you bypass the condition?

Also, I don’t think a GetBy is going to have changed row, it’s not changing anything, it’s just getting things, so that might be messing you up.

(Jose C Gomez) #19

Correct no changed row in GBI, use AnyRow

(Brandon Anderson) #20

A good way to test those is to also add a pop-up message to the false side. Make sure you can tell the difference between the two pop-ups. Then in both, do a table query to see what is being passed. Make sure to grab the RowMod if it’s available. That will help you figure out a lot of things much faster.