grist-core icon indicating copy to clipboard operation
grist-core copied to clipboard

Rows style depending on logged in user

Open CamilleLegeron opened this issue 1 year ago • 2 comments

Hi,

It's not a priority but could be great to customize rows style depending on logged in user.

For exemple a user can have access in read only to a lot of rows but can update only its proper rows. Today there is no visual difference between rows he can update and rows he can't. In the rows style we can't have access to "user.Email" to know how is connected. We can imagine an other solution declaring style on editable rows and read only rows

Wdyt about this feature ?

CamilleLegeron avatar Aug 30 '23 10:08 CamilleLegeron

This is a desirable feature. Implementing it would require some architectural changes.

Currently conditional formatting is implemented using calculations done with a hidden helper formula column. The state of that column is distributed by the back-end to all connected web clients. That means the state needs to be the same for all users. Which in turn means any particular user's identity can't be included as a factor in the calculation.

An alternate implementation of conditional formatting can be imagined, one that is done in the front-end, per client. The front-end does not have access to Python though, and conditional formatting rules can currently use unconstrained Python. While there would be ways of doing user-dependent calculations using the back-end Python "data engine", they aren't very appealing.

One option for progress: If conditional formatting rules were constrained, like granular access rules, then they could be run easily in the front-end, and giving access to user information would be no problem. It is a tricky trade-off though.

Another option: Since conditional formatting was designed and implemented, we happen to have gotten some experience with running Python in the front-end via Pyodide, in the grist-static project. In principle users could have their own private little data-engine on the side now, which could give new options for full-Python conditional formatting - but also a lot of questions.

Paging @berhalak @dsagal @anaisconce in case they have other ideas or perspective.

paulfitz avatar Aug 30 '23 13:08 paulfitz

How about a different feature: moving the rows conditional formatting from a Table level to the Section level. That way, each section could have it's own rules for formatting rows it shows. In my workflow I tend to have different pages dedicated for different users or tasks, and it feels natural to use a different styling rules in them.

Would it help in your use case @CamilleLegeron ?

berhalak avatar Aug 30 '23 15:08 berhalak