# Manage write and delete rule on client side
**URL:** https://discuss.tryton.org/t/manage-write-and-delete-rule-on-client-side/2392
**Category:** Feature
**Created:** [February 29, 2020, 2:27pm UTC](https://discuss.tryton.org/t/manage-write-and-delete-rule-on-client-side/2392 "2020-02-29T14:27:05Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [February 29, 2020, 2:27pm UTC](https://discuss.tryton.org/t/manage-write-and-delete-rule-on-client-side/2392/1 "2020-02-29T14:27:05Z")
## Rational
The clients supports the access right on models and they disable the corresponding buttons.
When a model has record rules for the write and delete rights, we rely on the server validation only which is not ideal for the experience. It will be better if the client could display as read-only record for which the user does not have the write right and disable the delete button if he does not have the delete right to any of the selected record.
## Proposal
I think we could send to the client the write and delete rights of each record read using _private_ variable (like the `_timestamp`).
The simplest way should be to add to the `SELECT` query two column that contains a sub-query based on the `ir.rule`. If there is no rule, the query is replaced by a fixed value.
Those fields should be explicitly requested on the `read` call.
## Implementation
- [Manage deletable and writable state from ir.rule on the client side (#9357) · Issues · Tryton / Tryton · GitLab](https://bugs.tryton.org/issue9357)
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [February 29, 2020, 2:29pm UTC](https://discuss.tryton.org/t/manage-write-and-delete-rule-on-client-side/2392/2 "2020-02-29T14:29:05Z")
There could be some concern about the performance. This may have an negative impact on the read.
I think that once we have [removed the company record rules](https://bugs.tryton.org/issue4080), there should be a very low number of impacted model with rules.
---
### Author:  [@pokoli](https://discuss.tryton.org/u/pokoli)
#### Post date: [February 29, 2020, 3:04pm UTC](https://discuss.tryton.org/t/manage-write-and-delete-rule-on-client-side/2392/3 "2020-02-29T15:04:35Z")
> [@ced](#):
>
> there should be a very low number of impacted model with rules.
So I’m not sure if this feature it is worth its effort.
---
### Author:  [@nicoe](https://discuss.tryton.org/u/nicoe)
#### Post date: [May 15, 2020, 4:55pm UTC](https://discuss.tryton.org/t/manage-write-and-delete-rule-on-client-side/2392/4 "2020-05-15T16:55:07Z")
> [@ced](#):
>
> Those fields should be explicitly requested on the `read` call.
How do you think this should be handled?
A specific attribute on the Model (since there is an `ir.rule` it would be a “global” setting anyway) or more something that should be specified in the `ir.action` or even the `ir.ui.view` of said model?
I tend to prefer the Model idea but there might be another issue that I haven’t expected.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [May 15, 2020, 5:00pm UTC](https://discuss.tryton.org/t/manage-write-and-delete-rule-on-client-side/2392/5 "2020-05-15T17:00:02Z")
> [@nicoe](#):
>
> How do you think this should be handled?
Like the `_timestamp` in `ModelSQL.read`.
> [@nicoe](#):
>
> A specific attribute on the Model (since there is an `ir.rule` it would be a “global” setting anyway) or more something that should be specified in the `ir.action` or even the `ir.ui.view` of said model?
It should be request on all read of the client.
---
### Author:  [@nicoe](https://discuss.tryton.org/u/nicoe)
#### Post date: [May 15, 2020, 5:03pm UTC](https://discuss.tryton.org/t/manage-write-and-delete-rule-on-client-side/2392/6 "2020-05-15T17:03:31Z")
> [@ced](#):
>
> It should be request on all read of the client.
OK I got it, I misunderstood the phrase.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [April 12, 2021, 4:00pm UTC](https://discuss.tryton.org/t/manage-write-and-delete-rule-on-client-side/2392/7 "2021-04-12T16:00:04Z")
This topic was automatically closed after 2 days. New replies are no longer allowed.