There is serious bug in Desktop client 2015.11.82.0 - when the application role is set as read only, screen form stand in read/write mode which have serious consequences for system administrators.
Isn’t it possible that the user has the same application role assigned once read-only once not?
Certainly not. Was tested with only one role assigned. Web version working as expected.
Update: The problem only occurs if you have the following setting turned on in AsapSettings.config:
<ActivateReadOnlyRoles>true</ActivateReadOnlyRoles>
I will inform you about the fix.
After examining your data I can see that the problem is caused by setting a * value into Roles property of an alternative screen section you have created on the BusinessPartner entity.
There might be a slight difference in behavior of the web client but putting star into this property is not really correct and you should remove it. That will also fix your problem.
I have removed “*” value from Roles of alternative screen section i.e. from BusinessPartner_ERP_Sales. Form behavior stays the same. This behavior was observed in other forms, not only in BP form.
In your case another * was used in an alternative to the whole screen. When removed it starts working as expected.
I am suspecting that in the web version (which you say works correctly) you have ActivateReadOnlyRoles set to false in AsapSettings.config.
If you still find other screens where it does not work, please check first for any alternatives or stars in the Roles properties. If not found and it still does not work as expected, please, let us know.
In another words, You say, that any stars in any alternative screen may cause disfunction on all other Read-Only screens ? Is it right ?
If the star is on the screen-level or section-level, than it works like this if you have the ActivateReadOnlyRoles setting turned on at the same time.
This behavior is caused by the way how read-only-roles for tab-pages were requested. You have to be very careful when designing roles inside the screens when this option is turned on.
What happens:
- The screen is being build
- Menu item’s role is checked. If the user has a Read Only status on this role, the whole screen is considered read only. If ActivateReadOnlyRoles is set off, we end here and everything is easy. But this is not our case, so we move on to the next step.
- Widget hierarchy is being parsed and added to the form.
- All widgets with no role specified are put in Read Only mode.
- Now let’s say a Tab Page has a role “MyRole”. Then it is checked if MyRole has a Read Only flag in current user’s roles.
- If it does not have a Read Only flag the Tab Page and all children widgets are considered writeable!
So this is a desired behavior.
Now there comes the star. It IS a role, so it is checked for having a Read Only attribute set. But since you cannot mark a star for Read Only so it is always considered writeable in the end.
The only way how to keep the Read Only status is not to enter any role into the Roles attribute of the widgets.
But maybe I misunderstood your last question. Putting a star to a single screen section of course does not change the behavior of other screens.
As I say – if you have any other screen that does not work NOW, please send me its name so I could look at it. For now the screens that did not work had a star which, when removed, made these screens working well. For anything else, just send me the screen’s name.
What comes to my mind is that setting the Roles property of the alternative screen section should not have any consequence on the resulting screen.
I filed a bug here.