Whats the best way to display edit an attribute on some forms and not allow any changes to it on others. I have a lot of these and would like a presentation attribute on a layout cell select for allow edit y/n type thing.
I would like it if the cursor wouldn't even stop on the attribute on the form and I can't create shortcuts for all of these.
Restrict Change
-
aware_support
- Posts: 7526
- Joined: Sun Apr 24, 2005 12:36 am
- Contact:
There are shortcuts and there is VIEW NO EDIT action that displays the entire form in the read-only mode. Finally, there is protection and access levels. Beyond this I really can't see why you would want to do it. If the same user can edit an attribute on one form, why can't he edit it on the other?
If these are different users, then these things should be controlled using the access level.
If these are different users, then these things should be controlled using the access level.
Aware IM Support Team
Let me give just a few examples and maybe you could assist in an easy way to do it without us writing a lot of rules or creating a lot of shortcuts.
We have a form that allows a user to create an order. The customer information is selected along with the billing and shipping address information. All the fields that are including are editable. And of course a lot more goes into this like salesmen, warehouse, etc.
As the user creates the order and keys line items the part numbers and sizes are entered. Totals are calculated and shipping type is added etc etc.
The order is completed and records created in several different tables for accounting, sales tracking, shipping etc.
Now comes the fun part. A lot of this information needs to be shown on other forms after it is created for other needs and should not be editable on those forms. However, some of it can and should be based on the FORM not on the access level.
Just a few examples. Once created we want a lot of the information to stay static, because it is what the customer gave us. Then there are other reasons. The Acct # can't be changed after created because it would screw up the links and billing etc etc. The ship to address and all the fields that go with it needs to be shown in the pick and shipping departments but shouldn't be changed. The salesperson shouldn't be changed after created but salespeople have a lot of this same information they need to see on different forms. Lets not even get into the back end stuff with accounting posting and the like or changing items after orders created.
Then again on some forms we need to be able to change things. For example, we need a form to change the shipping to address in case it was keyed wrong and then we also have a process to log who and why the change was made. This is a different form. Most of the time the sizes would be static but we have a process and form where that can be changed.
The only simple way I can see to do this is with shortcuts and about 60% of the attributes apply to this type of issue and shortcuts appear to be a crazy way to do it. Creating rules would be a lot of them.
How would you suggest we do it? Wouldn't a simple check box on the attribute under form creation for make attribute read only be helpful?
This appears to me to be much more of a FORM attribute then it is a rule or shortcut.
We have a form that allows a user to create an order. The customer information is selected along with the billing and shipping address information. All the fields that are including are editable. And of course a lot more goes into this like salesmen, warehouse, etc.
As the user creates the order and keys line items the part numbers and sizes are entered. Totals are calculated and shipping type is added etc etc.
The order is completed and records created in several different tables for accounting, sales tracking, shipping etc.
Now comes the fun part. A lot of this information needs to be shown on other forms after it is created for other needs and should not be editable on those forms. However, some of it can and should be based on the FORM not on the access level.
Just a few examples. Once created we want a lot of the information to stay static, because it is what the customer gave us. Then there are other reasons. The Acct # can't be changed after created because it would screw up the links and billing etc etc. The ship to address and all the fields that go with it needs to be shown in the pick and shipping departments but shouldn't be changed. The salesperson shouldn't be changed after created but salespeople have a lot of this same information they need to see on different forms. Lets not even get into the back end stuff with accounting posting and the like or changing items after orders created.
Then again on some forms we need to be able to change things. For example, we need a form to change the shipping to address in case it was keyed wrong and then we also have a process to log who and why the change was made. This is a different form. Most of the time the sizes would be static but we have a process and form where that can be changed.
The only simple way I can see to do this is with shortcuts and about 60% of the attributes apply to this type of issue and shortcuts appear to be a crazy way to do it. Creating rules would be a lot of them.
How would you suggest we do it? Wouldn't a simple check box on the attribute under form creation for make attribute read only be helpful?
This appears to me to be much more of a FORM attribute then it is a rule or shortcut.
-
aware_support
- Posts: 7526
- Joined: Sun Apr 24, 2005 12:36 am
- Contact:
Once created we want a lot of the information to stay static, because it is what the customer gave us. Then there are other reasons. The Acct # can't be changed after created because it would screw up the links and billing etc etc. The ship to address and all the fields that go with it needs to be shown in the pick and shipping departments but shouldn't be changed. The salesperson shouldn't be changed after created but salespeople have a lot of this same information they need to see on different forms
Well, this seems to be a very typical case for Aware IM. The solution is to use rules with PROTECT action. If something needs to stay static after it has been created, then the way to do it is create a rule:
IF NOT (Order IS NEW) Then PROTECT Order.AccountNo FROM ALL
This is clearly a business logic issue - making it form dependent seems to be wrong conceptually.
Then again on some forms we need to be able to change things. For example, we need a form to change the shipping to address in case it was keyed wrong and then we also have a process to log who and why the change was made. This is a different form. Most of the time the sizes would be static but we have a process and form where that can be changed
This means that conceptually the field IS EDITABLE (it is easy to register who made the change even without a process) so I still don't understand why it has to be enabled on some forms but not others.
Well, this seems to be a very typical case for Aware IM. The solution is to use rules with PROTECT action. If something needs to stay static after it has been created, then the way to do it is create a rule:
IF NOT (Order IS NEW) Then PROTECT Order.AccountNo FROM ALL
This is clearly a business logic issue - making it form dependent seems to be wrong conceptually.
Then again on some forms we need to be able to change things. For example, we need a form to change the shipping to address in case it was keyed wrong and then we also have a process to log who and why the change was made. This is a different form. Most of the time the sizes would be static but we have a process and form where that can be changed
This means that conceptually the field IS EDITABLE (it is easy to register who made the change even without a process) so I still don't understand why it has to be enabled on some forms but not others.
Aware IM Support Team