Skip to main content

Hi Experts,

Like most of you had asked before, we also have a requirement to enable/disable certain fields for users in certain projections in APP10 Aurena. We need to hide Cost and Pricing related fields from Inventory Part in Stock, Purchase Requisitions, Purchase Order and Work Orders for a group of users.

I have found many Community discussions on the similar requirement, with no promising outcome.

  1. Hiding from Column chooser is not helping us.
  2. Hide a standard column using page designer - IFS Cloud | IFS Community - this only hides the columns similar to column chooser, so the user can add it themselves.
  3. User shouldn’t be deprived from the Column chooser, as Aurena capabilities are valued by users.
  4. Creating new custom views - unnecessary complexity
  5.  Deleting the elements from Page designer for a new context- Possible to hide fields in Aurena? | IFS Community - we are worried about the implications on this. Could it result in unnecessary client validation issues?

Any other suggestions?

Also, your thoughts on point 5?

You can’t hide fields from views/lists for 100% sure if the user has access to column chooser without client modifications.

 

Anything you do at client level can be reversed based on context/profile if the user is allowed to change that, for instance through column chooser or its equivalent in Aurena.

 

The only way to actually keep the view as is but only modify it for a subset of users would be to modify the retrieved elements through client customizations based on logic that applies only to your business.

 

It can also, like you said, potentially have some negative impact if the field is needed for some other action and the data is no longer present, so it’s difficult to really tell whether your solution is secure.


@Vimukthi Mahakumbura I have done something similar for a customer in IFS Cloud. I do believe this would work in Apps10 - Aurena client.

What I did was the following:

  • create a new context with Page Designer
  • removed the fields from that context → published the changes done on the context
  • defined Appereance COntext Mapping rules - so that the less priviledged users will have the new context defaulted instead of Global context

One thing to watch for when working with multiple contexts is that when you will upgrade to IFS Cloud and start applying various Release Updates, you would need to rebase your Page Configurations

https://docs.ifs.com/techdocs/24r1/040_tailoring/225_configuration/200_client_configurations/400_rebase_configurations/


@Vimukthi Mahakumbura I have done something similar for a customer in IFS Cloud. I do believe this would work in Apps10 - Aurena client.

What I did was the following:

  • create a new context with Page Designer
  • removed the fields from that context → published the changes done on the context
  • defined Appereance COntext Mapping rules - so that the less priviledged users will have the new context defaulted instead of Global context

One thing to watch for when working with multiple contexts is that when you will upgrade to IFS Cloud and start applying various Release Updates, you would need to rebase your Page Configurations

https://docs.ifs.com/techdocs/24r1/040_tailoring/225_configuration/200_client_configurations/400_rebase_configurations/

 

Yeah, this works, but like I said, you won’t be able to 100% confirm this point :

 

If you delete the unwanted fields from the context in Page Designer, but those fields are somehow used in mappings in buttons or commands that the user would SOMEHOW still use, it’s likely those commands would no longer work :)

 

It’s a very rare case, but it could happen.

 

In addition like you said, rebasing page configurations for every IFS update is a bit of a pain, that’s why I try and avoid doing any context modification as long as I can :p


Reply