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!

Hi @Alexander Heinze ,

I don’t think we can use the ‘Editable’ attribute in all scenarios. The attribute is a Checkbox for most of the fields. Please see the screenshot below.

Kind Regards

Priyanka Cecilia

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.

It would be nice if we have all these features in 23R1. 

• I’m trying to modify the “Work Details” screen in MWO Service but not limited to this screen.
• Also a follow up question: Is it possible to Hide/Display screens in Mobile based on a condition? I’ve checked the Workflow Configuration but this is not feasible through that screen.
  • For example: Hide “My Work” screen in Mobile, if the Technician’s Work Status is “Off Shift”?

Kind Regards

Priyanka Cecilia

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.

Thanks @Alexander Heinze for your inputs on the “Editable” attribute available in 23R1.

Sure, I will raise another post for Hiding the screens. Appreciate the input on hiding the fields but we have other scenarios were we need to hide the entire screen. Therefore, would like to understand if we have any options.

Kind Regards

Priyanka Cecilia

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

Not sure if the 23R1 documentation is already accessible publicly, just try this: Conditional Fields - Technical Documentation For IFS Cloud

And this is from the Academy course “23R1 Experience Framework: New Features”:

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 tried a condition with 1,000 characters and it was still evaluated successfully.

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

It’s a framework capability, so it should be available almost everywhere, but I’m not in a position to confirm it. I doubt anyone will, so you will probably have to wait until the first versions become available.

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

I would let @James Ashmore answer that one.

@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

One more thing to add, the old link is not valid anymore as the structure has changed a bit recently. Please check back in a day on https://docs.ifs.com/techdocs/23r1/040_tailoring/225_configuration/950_configuration_references/060_knownlimitations/#list_of_values

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

@Alexander Heinze yes, they are now supported on MWO with 23R2.

@Priyanka Cecilia V  fyi. 

Thank you @Alexander Heinze 

Hi @Rukmal Fernando, does the conditions support if we refer to related entities other than the current entity in a specific screen in 23R2 MWO? Please advice.

Kind Regards

Priyanka Cecilia

@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.

Hi @Rukmal Fernando,

Would it be possible to let us know when we can expect this feature to be released?

Kind Regards

Priyanka Cecilia

@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

@Rukmal Fernando,

Yes, I was referring to the above scenario and also another scenario which we discussed earlier. For the above scenario we tested, it worked for certain functionalities but was inconsistent. Sure, please share the document once it is available.

Second scenario: While we try to set a baseline field in JtTask to be conditionally visible/editable based on a Custom field in JtTask, it doesn’t reflect the changes. (i.e., unable to use custom fields as conditional parameters). Is this something that will be enhanced or already available in 23R2? Please let me know.

Kind Regards

Priyanka Cecilia

@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.