Added user and view fields in model and feature #90
Conversation
|
Hi @vishalanandl177, please review the changes and let me know if you find any problem. |
| @@ -96,11 +96,11 @@ def added_on_time(self, obj): | |||
| added_on_time.short_description = 'Added on' | |||
|
|
|||
| list_per_page = 20 | |||
| list_display = ('id', 'api', 'method', 'status_code', 'execution_time', 'added_on_time',) | |||
| list_display = ('id', 'api', 'user_id', 'method', 'status_code', 'execution_time', 'added_on_time',) | |||
| list_filter = ('added_on', 'status_code', 'method',) | |||
There was a problem hiding this comment.
I think it will be better if we add 'user_id' in list_filter too!
There was a problem hiding this comment.
I'm very sorry, I don't think it's a good idea because it will make django admin dashboard look not good as list of user_id can be very long if there are many users, @vishalanandl177 what's your take on this?
|
@rkisdp any idea when this PR will merge and a new release will be out? |
@ken-turgnate Sorry but I'm not the maintainer of this repository, so can't do or tell you anything about this. |
|
Apologies @rkisdp . @vishalanandl177 Any idea on when this land and get released? Thanks |
|
Hi @vishalanandl177, any update on this PR? if there something you want me to change? I want to add more features in this module, please let me know. |
|
I'm interested in having the user too. This package is great, but it would be important to know WHO made the call if it was an authenticated user or not. |
|
@vishalanandl177 Are you still maintaining the Repo ? |
|
I cannot merge because doing so may violate certain policies, as observed in various enterprise companies. |
|
@vishalanandl177 I am very sorry. Can you please tell me what policies I am breaking in this commit? I will fix them. |
|
Based on my recent conversations with several enterprise companies, developers should not have access to user information. Allowing developers to use customer data for personal interests poses a risk. |
|
TL; DR: let's make them optional, disabled by default. Hi fellow users and devs, I have been employed in multiple SP500 enterprises that takes these risks seriously. In such companies segregation of duties is required for example by Sarbane Oxley Act. Segregation of duties means that if you can change code (you are a developer), you cannot read production DB. Only non-production. So it also means, that you cannot read any production data. You simply don't have access to it. You can only access non-production anonymized sample data in non-production DB. If they give production data access to regular developers, they miss the point of Segregation of Duties. And only in special cases if it not possible to fix the bug without accessing those non-production data, temporary access to production data is allowed, with special approval. Source: https://www.securends.com/segregation-of-duties/ (a bit commercial, but correct) So I think storing ID of the user is perfectly OK. However, to be on the safe side, it can be an option in settings.py, so one can it enable explicitly only if needed. Would it be the way to go? |
Added 2 extra fields with complete flow to added the information into the database.