Hi,
I am loving the new editable and groupable queries feature in the beta version but I am wondering how hard it would be to be able to make certain fields in the query non-editable and some editable. For example, you might often want to show some information about a record such as an identifier (name, id # etc...) so that the user can see which record they are looking at/editing, but not want them to be able to change that field for obvious reasons.
On the config tool front end, it would be as simple as adding a new column in the query field selection list, on the back end however would it be possible? This would make these queries significantly more useable.
Cheers,
Pete
Version 4 editable queries
-
aware_support
- Posts: 7525
- Joined: Sun Apr 24, 2005 12:36 am
- Contact:
Hi,
No, I typically use more advanced logic for determining editability based on fields such as date, status etc... Without the ability to control record level editability or more particularly field level editability within editable queries, the only solution is to eliminate any records or fields from that query that you don't want to have changed on you.
This is a shame because if you could control the editability at a field level only for a given query, the editable queries could become a true workhorse. As it is, I would need to have the user jump out to non-editable form versions of the record (largely using html cells) to allow the user to see all of the relevant fields within the record and control which ones they could edit on that particular form, thus defeating the benefit of the editable queries.
I often find that I have situations where a user with limited access rights is allowed to create a record but only allowed to edit certain fields within that record after the record has reached a certain status level. I realize that there are always workarounds and access levels are only one way to control editability, I am speaking specifically about the new editable queries and how they could be made exponentially more usefull in real world situations that we run across on a daily basis.
Anyway, please treat it only as a suggestion and something to think about. It you feel it might be possible yet, not a high priority please pm me and let me know whether there might be an opportunity for me to fund the change.
Cheers,
Pete
No, I typically use more advanced logic for determining editability based on fields such as date, status etc... Without the ability to control record level editability or more particularly field level editability within editable queries, the only solution is to eliminate any records or fields from that query that you don't want to have changed on you.
This is a shame because if you could control the editability at a field level only for a given query, the editable queries could become a true workhorse. As it is, I would need to have the user jump out to non-editable form versions of the record (largely using html cells) to allow the user to see all of the relevant fields within the record and control which ones they could edit on that particular form, thus defeating the benefit of the editable queries.
I often find that I have situations where a user with limited access rights is allowed to create a record but only allowed to edit certain fields within that record after the record has reached a certain status level. I realize that there are always workarounds and access levels are only one way to control editability, I am speaking specifically about the new editable queries and how they could be made exponentially more usefull in real world situations that we run across on a daily basis.
Anyway, please treat it only as a suggestion and something to think about. It you feel it might be possible yet, not a high priority please pm me and let me know whether there might be an opportunity for me to fund the change.
Cheers,
Pete
-
aware_support
- Posts: 7525
- Joined: Sun Apr 24, 2005 12:36 am
- Contact:
Is this really at a query level or at a business logic level? I mean if you cannot use access levels, can you use PROTECT rules?
Are you saying that for different queries on exactly the same object in exactly the same status you would want to allow editing certain attributes for some queries but not others? Why would you want that?
Shouldn't a PROTECT rule that checks the status of the object solve your problem? (by the way, this doesn't work properly in the beta version, so don't try it yet - we will fix it for the final release)
Are you saying that for different queries on exactly the same object in exactly the same status you would want to allow editing certain attributes for some queries but not others? Why would you want that?
Shouldn't a PROTECT rule that checks the status of the object solve your problem? (by the way, this doesn't work properly in the beta version, so don't try it yet - we will fix it for the final release)
Aware IM Support Team
Thanks for your response Vladimir,
Yes, you have defined correctly what I am trying to do. It all has to do with streamlining the user experience. Here is an example of what I mean.
Let's say that you have a BO called Employee and it has a number of attributes where one of the attributes is the employee name and another attribute is the status of the employee. For this example I would like to offer the user a menu item to edit the employee status fields efficiently. The editable query is now the perfect tool of choice because they can update all of the various employee status values while on the same screen. Because I want them to only focus on the task at hand which is to edit the status fields, I don't want them to click on the employee name field and change it whether intentionally or not. On the other hand, I might want to offer them either another editable query or dedicated form for changing the employee name perhaps because one of the employees got married and their last name changed.
This isn't a great example but it does show that there would be great benefit to being able to 'protect' an attribute at an editable query level rather than on a more global level as is the case with access levels or protect rules.
Pete
Yes, you have defined correctly what I am trying to do. It all has to do with streamlining the user experience. Here is an example of what I mean.
Let's say that you have a BO called Employee and it has a number of attributes where one of the attributes is the employee name and another attribute is the status of the employee. For this example I would like to offer the user a menu item to edit the employee status fields efficiently. The editable query is now the perfect tool of choice because they can update all of the various employee status values while on the same screen. Because I want them to only focus on the task at hand which is to edit the status fields, I don't want them to click on the employee name field and change it whether intentionally or not. On the other hand, I might want to offer them either another editable query or dedicated form for changing the employee name perhaps because one of the employees got married and their last name changed.
This isn't a great example but it does show that there would be great benefit to being able to 'protect' an attribute at an editable query level rather than on a more global level as is the case with access levels or protect rules.
Pete
FYI,
Support has agreed that this would be a benefit and have agreed to implement it in a future version. For my part, I have agreed to contribute financially towards this development. I encourage all users to consider contributing to custom developments for the benefit of all. After all, it is in all of our best interests to support AwareIM.
Cheers,
Pete
Support has agreed that this would be a benefit and have agreed to implement it in a future version. For my part, I have agreed to contribute financially towards this development. I encourage all users to consider contributing to custom developments for the benefit of all. After all, it is in all of our best interests to support AwareIM.
Cheers,
Pete