Open toffehoff opened 4 months ago
@toffehoff With the new permission model, user management will be much simpler.
@toffehoff With the new permission model, user management will be much simpler.
Hi @samshara actually this is a different thing. Agree that user management will be easier with new model - however Henk's feature request is about how to know whether people are still eligible to hold the access that they do. e.g. whether someone has left their job at an NS, or is no longer a volunteer etc. I.e. how IFRC admins know when they need to do the user management. Cheers
Hi @samshara I definitely support a way more simplified permission model. But the issue is not the permission model, but whether user should not be able to login anymore (because e.g. left the organization). Currently in IFRC (and also several NSs), the moment your contract ends, you're not able to login to your email etc. This will immediately be de-activated. This does not apply to GO. For instance: if I were to leave the IFRC, my account (henk.hoff@ifrc.org) would be blocked and am not able to login to workplace (O365, email, fednet, etc). But I could continue to use GO, because there is no (automated) mechanism to revoke access rights. We could do some check for IFRC accounts, but not for NS accounts (or non-RCRC email address accounts). If our policy is: "once you have access, you have access for life", then this is not an issue... But I doubt that that is our policy :-)
@toffehoff @nanometrenat
I don't think there is an easy solution for this. One solution would be adding a contract_end
date during registration or through the admin panel. This would still require manual intervention. I believe this is out of the scope for IFRC Go, as it depends on NS and IFRC IT infrastructure. We would need some way to verify if the email is valid within the organization; only then could we remove the access rights.
Hi @samshara, I'm not proposing to add expiration dates of contracts in the system. The basic functionality of what I propose is this: Every year (or half year, or ...) your account will be de-activated (unless you are superuser) and you will be send an email in which there is a link to re-activate your account. Click on it, and you're active again. If you don't have access to you mail-account anymore, you won't be able to activate. The assumption is that if you leave the IFRC or the NS, your mail address won't work anymore. Or course this doesn't not fly is you have a generic email address. Therefore, in that case, there should be an alert to those who approve pending accounts that a generic email account has prolonged its access. It is up for this approve-person to follow up or not.
@toffehoff Thanks for the proposed solution. We could go with the flow you describe. I will bring this up with the Development team, and let's discuss it with the IM team as well.
cc @szabozoltan69 @tovari
After approval of an account, there is no check whether that account should still have access after some time There is process for getting an account in GO. You need to have a validated email-address and if it is from a domain on the white-list you can direct access. Otherwise, it needs to be approved by the region. However, once you have access, there is no process to de-activate an account if the person (for instance) left the Red Cross, and should no longer have access anymore.
Describe the solution you'd like Automated re-verification of email addresses. Meaning: Every so many times (e.g. half year) users will get an email in which they need to confirm their access to GO, by clicking on a link. When the email is sent, the account is set to in-active. When they click the link, the account is activated again. This should work fine for emails from the whitelisted domains. Assuming that the NS is actively de-activating accounts after people have left the organisation. For email addresses not on the white-list, when the person has clicked the link to confirm continuation of access, there should also go a mail to the regional representative indicating that that specific account has prolonged his/her access. Adding to that, the person(s) with Staff Status of the respective NS where the account is from should also receive the message that the account has been prolonged. This also gives a responsibility to the NS on who has access and who not.
Of course there are variations of this solution. Bottomline, we need to have a process wherein we validate if users still are eligible for access to GO