Created on 2018-03-23.17:59:01 by wise, last changed 43 months ago by ced.
So I mark as invalid.
I agree that should invalidate it. The way to improve it is by implementing issue4207
For me, it is not a security issue because it is a behavior (or more an "non-behavior") that is known with issue4207. There are many places in modules where specific code is written to enforce a kind of "readonly". Also the field access already exists if someone wants to restrict it. Side note, it is not linked to sao at all because it is not the client that should enforce the access rights. So I'm in favor of invalidating this issue.
Steps to reproduce I create a party as the screenshot https://pasteboard.co/HdfGj0t.png I remove readonly attribute on field (implemented readonly on states) from html https://pasteboard.co/HdfGvxQ.png I change the code party and save change https://pasteboard.co/HdfGE0Y.png Treeview after save change https://pasteboard.co/HdfGTcY.png Someone with some technical knowledge on html can remove readonly attribute and bypass restrictions model when we use dynamic states.
|2018-03-26 22:01:00||ced||set||status: chatting -> invalid|
messages: + msg39434
|2018-03-24 11:36:17||pokoli||set||messages: + msg39312|
|2018-03-23 18:33:03||ced||set||status: unread -> chatting|
component: + trytond, - sao
superseder: + Enforce readonly on field
messages: + msg39284
Showing 10 items. Show all history (warning: this could be VERY long)