Read Protect

RocketRod

Ive started another topic here so it has the right title. The issue of not being able to see information displayed on a screen when the READ PROTECT rule is used has been it seems around for a very long time. It is a powerful feature of this great package and so I believe it does need to be fixed. IE is still used widely and will continue to be so and so for developers who want to sell applications it is a must to be fixed. It is great to be able to protect information based on rules in a BO.

My suggestion therefore is to take a different approach so the issue is fixed once and for all time. The displaying of attributes as READ ONLY approach seems to be dependant on browsers and these will continue to change overtime as they are under the control of others.

The READ PROTECT to me is used by configurators so that a user can display a form on a screen but not change any of the information. So to me just remove the SAVE button off EDIT forms and leave the CANCEL button!

Of course I have no idea how easy that is for support to do but to me it would be great as all information on the form would display normally. I would leave calculated fields as is as configurators can use HTML to resolve that issue. Also adding and deleting once again can be handled by the configurator.

So my questions are:

What does everyone think of this?
Does anyone have another approach?
Support how easy would it be to do this if others agree that its a good idea and when could it be done?

Cheers Rod

aware_support

This would be relatively easy to implement, but it will have to be an option somewhere. The default behaviour should remain as is.

RocketRod

I meant PROTECT rule not READ PROTECT rule of course as the latter would not change. Also I meant the CLOSE button and not CANCEL! Sorry I was up at 5am this morning writing this!

Sounds great to add it as an option. Would it be on each BO say on Form buttons or would it need to apply globally? This would be fantastic as it would solve my problem and I'm assuming lots of others. Hope it can be done ASAP.

Cheers Rod

pbrad

Hi,
Maybe I am missing something here but two solutions that already exist that simulate the functionality of removing the save button and keeping the cancel button are VIEW form and showing all attributes as html which is not editable but easily readable.

My understanding was that people (including me) are looking for a way to conditionally protect one or more text fields on a form but leave the text easily readable which it currently isn't. I don't see how removing the save button would allow for conditional protection of specific attributes on a form?
Cheers,
Pete

aware_support

What Pete says is true - the option to remove the Save button wouldn't work for conditional protection. An option to show protected fields as HTML would work, though.

nlarson

if you show them as HTML conditional formatting should be preserved please. This is an issue I have now as using an HTML attribute on forms was was my elected work around for all my calculated fields.

RocketRod

If you use VIEW form you have the same issue with everything being too light. That's my point. Why display the attributes as READ only when there is no SAVE button? Yes a user might type something in on the screen assuming they can but they will soon learn that they can't. I much rather have this issue than them not being able to read anything on the screen. My suggestion was to make PROTECT work the same as VIEW form , i.e. no SAVE button yet don't make the attributes READ only.

If you are protecting a few attributes then yes use HTML but I need and I'm sure others do need to protect all attributes for a BO. So I don't see that I have any options at all at the moment. I can't use VIEW form due to the same lightness issue and I certainly can't make all attributes on all BOs html.

So how about changing the VIEW form to not read protect the attributes and also allow conditional applicability on the SAVE form button. Then I could have a rule such as

IF BOInvoice.Status='Closed' THEN Protect BOInvoice From Users.

This would reduce the lightness issue to a small percentage of what it currently is.

Cheers Rod

pbrad

Hi,
I guess that it would be handy to be able to manually hide the save button under certain conditions but I think that it would be a lot more useful to be able to select to convert 'protected' attributes to html fields. I rarely need to totally protect a whole form, I often need to protect individual attributes.

I do have one other idea which would also be highly useful. If we could conditionally hide separator rows and choose whether to show the separator row border and if by hiding the separator row, we automatically hid any attributes bound within the separator row and the next separator row, we would end up with a powerful tool for conditionally controlling the visibility of entire sections of a form (similar to hiding a tab). In the example from this thread, we could show the panel that holds html attributes if we wanted them to be protected and hide that section and show the section that holds writable attributes otherwise.

Cheers,
Pete

nlarson

I sympathize with they sentiment and would like t see a resolution to these issues but these ideas idea seem to side step the fundamental issue which is a style problem. In my use case read-only calculated data sits next to input fields which are typically editable, so no save button is a non-starter for me.

A quick search on the Sencha forums show this to be a common issue with EXTJS users with a number of suggested solutions all of which are based on style changes to the .css

I can’t really speak to how this might impact Aware, but the idea that there needs to be new functionality created to sidestep a .css issue seems like using a sledge hammer to swat a fly. If it was me, I'd be looking towards some custom .css. even though that will require a departure from EXTJS's out of the box framework (which is always a PITA).

kklosson

I don't personally have any skin in the game. I use lots of read protection and to me, even in IE, they seem readable. "Disabled" is a control state with a definitive function and meaning, both on the web and the desktop. The inability to save, in my opinion, would just confuse the user, plus in my case, I have mixed protection states on various controls for a very good reason. This is how the world works.

I would suggest a campaign to the EXTJS developers to make disabled controls more readable.

RocketRod

Thanks everyone. In summary it looks like:

Support consider adding some additional conditional functionality to forms.
Someone either AwareIM or EXTJS developers address the CSS issue.

For my part I'll probably stop using PROTECT as my users just constantly complain about not being able to read the screen and move where I can to:

Placing a rule on each BO to use REPORT ERROR instead.
Embedding a BO attribute in the form caption to alert the user to either changes allowed or no changes allowed.

This will overcome my issue with readability, maintain DB integrity but is not ideal as a user will be able to make changes but not save them.

Cheers Rod