Change Details

The GPDR consultant of WMIT needs to monitor who has access to the platform and what are their privileges. The problem was: our GDPR consultant should not be really a Super Administrator just to do that thing. Probably most people do this, but we don't like that, since the figure of a Super Administrator should be a technical one with write access to everything, and that is not really the definition of an external consultant that should just see in Read-Only the list of the Users and their access levels. So, I implemented a fix in the WMIT LimeSurvey in order to allow people with "Users read" privileges to see Users' Role names. In order to comply with the libre license of LimeSurvey, I shared my patch under the same license, and I also proposed it upstream: https://github.com/LimeSurvey/LimeSurvey/pull/3048/files We can close this bug when: [X] we have a patch working in our local installation [ ] LimeSurvey approved our patch [ ] LimeSurvey landed our patch in master branch [ ] we update our LimeSurvey and have fun Note that, at the moment, we just implement that patch manually on server `intreccio` on this file: ``` /var/www/limesurvey/production/application/models/User.php ```

The GPDR consultant of WMIT needs to monitor who has access to the platform and what are their privileges. The problem was: our GDPR consultant should not be really a Super Administrator just to do that thing. Probably most people do this, but we don't like that, since the figure of a Super Administrator should be a technical one with write access to everything, and that is not really the definition of an external consultant that should just see in Read-Only the list of the Users and their access levels. So, I implemented a fix in the WMIT LimeSurvey in order to allow people with "Users read" privileges to see Users' Role names. In order to comply with the libre license of LimeSurvey, I shared my patch under the same license, and I also proposed it upstream: https://github.com/LimeSurvey/LimeSurvey/pull/3048/files We can close this bug when: [X] we have a patch working in our local installation [ ] LimeSurvey approved our patch [ ] LimeSurvey landed our patch in master branch [ ] we update our LimeSurvey and have fun Note that, at the moment, we just implement that patch manually on server `intreccio` on this file: ``` /var/www/limesurvey/production/application/models/User.php ``` The current problem is: when we update, we obviously lose that change.

The GPDR consultant of WMIT needs to monitor who has access to the platform and what are their privileges. The problem was: our GDPR consultant should not be really a Super Administrator just to do that thing. Probably most people do this, but we don't like that, since the figure of a Super Administrator should be a technical one with write access to everything, and that is not really the definition of an external consultant that should just see in Read-Only the list of the Users and their access levels. So, I implemented a fix in the WMIT LimeSurvey in order to allow people with "Users read" privileges to see Users' Role names. In order to comply with the libre license of LimeSurvey, I shared my patch under the same license, and I also proposed it upstream: https://github.com/LimeSurvey/LimeSurvey/pull/3048/files We can close this bug when: [X] we have a patch working in our local installation [ ] LimeSurvey approved our patch [ ] LimeSurvey landed our patch in master branch [ ] we update our LimeSurvey and have fun Note that, at the moment, we just implement that patch manually on server `intreccio` on this file: ``` /var/www/limesurvey/production/application/models/User.php ``` The current problem is: when we update, we obviously lose that change.