Hiding fields from user (role)

[Jeffrey Bostoen]

Say there's some sensitive information in a CI... Let's say, a regular user is allowed to view a person; but not the phone number for emergencies.

Can this be accomplished using roles?

[Vincent @ Combodo]

That's not available out of the box, but overwritting GetAttributeFlags() allow you to hardcode some hiding logic based on profiles for example

[Jeffrey Bostoen]

Thanks, I'll look into that.

[Jeffrey Bostoen]

Finally getting to the point where I really need such a feature.

I was searching the documentation and the board a bit.

I noticed this reply: You could give a look at those functions, they can force a field to be read-only:
public function GetAttributeFlags($sAttCode, &$aReasons = array(), $sTargetState = '') which is called before displaying the edit screen or GetInitialStateAttributeFlags() which is called before creation screen.

I also read https://www.itophub.io/wiki/page?id=2_5_0%3Acustomization%3Acascade-update .

It seems to suggest GetAttributeFlags() is only called on modification. Is it possible with the same method (or others) to also hide this field during viewing details of for example a Person? (and also in search results)

[Guillaume Lajarige]

Hi Jeffrey,

Yes, the GetAttributeFlags() method is called when viewing an object as well. So it should suit your needs :)

Guillaume

[Jeffrey Bostoen]

Thank you Guillaume for your reply. I'll see if I can share an example back here as token of my appreciation! :)

[Guillaume Lajarige]

That would be great :)

[Jeffrey Bostoen]

It seems to work on the detail page, even when just viewing; but the field still appears in result lists?

[Guillaume Lajarige]

Do you mean result lists when browsing through the console or the lists shown in linkedset tabs of objects?

[Jeffrey Bostoen]

I meant the result lists when browsing through the console.

So when I search for Persons, or just use the iTop-wide search (top search bar).

[Guillaume Lajarige]

Then you should simply configure the "list" zlist to remove the unwanted fields. Each classes has a "list" zlist to define which fields are displayed in a standard list (same goes with "details" zlist for object properties)

[Jeffrey Bostoen]

I'll do that. But the initial idea was that there is some information which is more sensitive, in just one or two fields of an entire class (and it's not practical to create a new class for those to define separate userrights).

Furthermore, you can see the attribute when using CSV/Excel export (or even just previewing it).

So I was kind of hoping GetAttributeFlags() or something similar would work for the result lists as well, as it may be easy for those who have access to see that information in the lists. "lists" zlist only seems to define the default view, but when modifying, non-privileged people can still add and see the attribute.

( There might be more and more requests like this with GDPR in mind )

[Guillaume Lajarige]

Unfortunately it is not possible natively or with a nice angle.

That being said, there is an ugly hack to do so (would also work when viewing an object). You can overload the GetAsHTML($sAttCode, $bLocalize) method of your class with something like:

public function GetAsHTML($sAttCode, $bLocalize = true)
{
    if($sAttCode === 'phone')
    {
        return '****';
    }
    else
    {
        return parent::GetAsHTML($sAttCode, $bLocalize);
    }
}

This will work in the console -not the portal- but I would not recommend it.

[Jeffrey Bostoen]

Would that work to hide it in exports as well?

I'm trying to come up with the best possible solution; since it's only really one text string (like in your example). Linked sets or something like that don't make sense, and I noticed the count_min and count_max are not implemented either.

[Guillaume Lajarige]

It depends on the type of exports. You would have to overload GetAsXML and GetAsCSV as well.

[Jeffrey Bostoen]

Thanks. I got it working for the details page and the lists of a Class; also just made it track no changes; and it seems to hide it when previewing and actually exporting to CSV.

When exporting to Excel, I still see the value in the on-screen preview in iTop.
For some reason (maybe because of my GetAsXML()), the export just fails.

Not sure what to return there, I thought just "" or return Str::pure2xml((string)"";

[Guillaume Lajarige]

Do you have an error message on your browser / error log ?

[Jeffrey Bostoen]

No error message in the backend.

In the frontend, it just says the export failed (I also tried it with only one column, same result, only happens when exporting to Excel/PDF. CSV is fine.) The preview works fine.

I removed all extensions related to "person", still an error.
Could it be a Windows / XAMPP issue instead, are any special permissions needed to create Excel files on Windows / XAMPP ?

[Jeffrey Bostoen]

Guillaume, could you give me an example please of what the GetAsXML() method should return?

Which ones do I need to override for Excel, PDF?

[Pierre Goiffon]

Hi Jeffrey,
Sorry it's been a long time since you asked, but you may take a look at the new AttributeSet / AttributeTagSet classes that were introduced in 2.6.0

[Jeffrey Bostoen]

Thanks for bumping the thread. How exactly should these attribute types help, Pierre? :)

I still need to investigate this; the only other option I've considered so far is storing that one field which is more sensitive (GDPR) in a separate class instead.

[Pierre Goiffon]

take a look at the new AttributeSet / AttributeTagSet classes

How exactly should these attribute types help

Because we had to implement exactly all of those methods :)

[Jeffrey Bostoen]

It's still not very clear to me how exactly the AttributeTagSet would help though?

[Pierre Goiffon]

I was reacting to your question about GetAsXML method... but right, this may not be of a great help

[Jeffrey Bostoen]

Sorry to bump this, but I assume the issue starts here:

https://github.com/Combodo/iTop/blob/96334d859aaa695aa128fe562256dad1cd6603cf/application/excelexporter.class.inc.php#L196

So, I'd either need to be able to overwrite that class; or the GetEditValue() methods of AttributeDefinition?

Or would it be better to create a custom AttributeDefinition for this attribute instead?