IFS Cloud 22R2 - Editable Function in Page Designer

I made the same observation and I think that this limitation was removed in 23R1, along with 

the ability to conditionally:

• Show & Hide Fields

• Control Mandatory/Required Fields

• Control Read Only Fields

• LOV Filtering

• Enumeration Filtering

• And more…

What page are you trying to modify? I can check the behavior in 23R1.

This has definitely improved in 23R1, you can put a formula into the “Editable” attribute:

For hiding an entire screen I would post a new question in this forum so that the MWO experts can respond. Worst case - using the attribute above - you could hide all job details and only show a message “job details available after login”. Benefit of that approach is that it’s less confusing for the user. When the entire screen is hidden, I guess many people will complain until they understand they need to login first.

Hi @Alexander Heinze, two follow up questions.

• Is it possible to add conditions to a button/command group in the Editable attribute related to other Entities? 
  • For example: to hide the “Show Breaks” button in My Work screen in mobile when the Shift Status is “Off Shift”?

• Do we have any document outlining the valid syntaxes to be used in the Editable attribute?

Please let me know.

Kind Regards

Priyanka Cecilia

Thanks @Alexander Heinze. I will check with the above information.

Do we have any restrictions on the field length for the ‘Editable’ and ‘Visible’ attributes? In case, we have many conditions to check in these fields and if there is a restriction, I would like to be aware of it. 

Kind Regards

Priyanka Cecilia

I don’t know what the “Editable Function” attribute does, however if you wanted to specify whether a field is editable or not you should use the “Editable” attribute.

Way more capabilities coming in that space in 23R1!

@Alexander Heinze, I would like kindly confirm if this feature is available for all Pages in 23R1 (both Cloud and mWO Service) or only for specific pages? Because we have requirements to add constraints to fields in various pages. 

Thanks.

Kind Regards

Priyanka Cecilia

Hi,

I saw this Known Limitation mentioned in 23R1 IFS Technical Documentation. I would like to confirm if this is related to this post for accessing Editable attribute in mWO Service.

https://docs.ifs.com/techdocs/23r1/040_tailoring/225_configuration/700_configuration_references/060_knownlimitations/#list_of_values

Kind Regards

Priyanka Cecilia

@Priyanka Cecilia V and @Alexander Heinze I work with James and I can jump in on this. There is actually limited support for setting Visibility, Editability and Requiredness on fields in Mobile, so we’ve updated the 23R1 technical documentation to reflect that (and thanks for spotting it!).

The link above might not reflect this right away, but should do so in a day or so to read: “IFS Cloud Mobile Apps have limited support for changing attribute properties such as Visibility, Editability & Required in Page Designer.”

Cheers,

Rukmal

@Rukmal Fernando Looking at the new features for 23R2, the properties “editable”, “visible”, and “required” should be supported on MWO, correct?

@Priyanka Cecilia V  fyi. 

@Priyanka Cecilia V in general, yes, just like the example we looked at together, we can use references to refer to related entities.

However, you might recall one instance where the referred entity had multiple records and we were evaluating against the incorrect one, and that’s turned out to be rather complex so we’re still working on that.

@Priyanka Cecilia V I think you’re referring to the scenario we discussed previously, of setting a field from JtTask to  be conditionally visible/editable/required based on a reference to JtExecutionInstance right?

We concluded the technical investigation on that literally today, and that specific scenario is unfortunately not something we can handle. The reason is that we came to realize that even though the projection has a reference from JtTask to JtExecutionInstance, in reality, a single JtTask instance will effectively be a wrapper for multiple JtExecutionInstance instances, so there is no logical reference from JtTask to JtExecutionInstance. The reference we tried to use is one that has been added to make some functional implementation easier.

The right way to approach references is to look at the Entity definition. Any associations defined between entities and also reflected as references on the Projection level can still be used.

I hope the above is clear and is some help, and we will be documenting this limitation and the right way to use references. Once we document this guidance properly, I will also share that with you.

Best regards,

Rukmal

@Priyanka Cecilia V the second scenario is a limitation that we’ve not been able to investigate deep into yet. Once we look into it, if we find a workaround, we will share that too on both the documentation and on this thread.