[xwiki-devs] [Proposal] Remove XWiki.User enable property and introduce email_check property
Hi everyone, I recently (in XWiki 11.6RC1) introduced a new property "enabled" in XWiki.User as part of https://jira.xwiki.org/browse/XWIKI-12654 to distinguish between inactive users (who have not confirm their registration with the token sent by email), and disabled users (who are deactivated by an admin, or by a security mechanism). Now as Marius noticed those two properties are quite redundant, especially when you want to know which users are really active. So it introduces unnecessary complexity and we might even need to change existing extension to check enabled users (cf the last comments on XWIKI-12564). So before doing those changes, I propose to fix immediately the issue by removing that newly introduced property and by introducing a new property only for assessing that users' email are checked. Then we will only have to check "active" property to check if a user is active or not, and we could rely on it to set them enabled or disabled in the admin. The email_check property would be used only for the check email mechanism, so it will avoid any confusion in the semantic. WDYT? Simon -- Simon Urli Software Engineer at XWiki SAS [email protected] More about us at http://www.xwiki.com
+1 never been a big fan of the duplicate. Would still be better to have a migration in case someone used the new disabled property to avoid bad surprises with security Le jeu. 22 août 2019 à 16:01, Simon Urli <[email protected]> a écrit :
Hi everyone,
I recently (in XWiki 11.6RC1) introduced a new property "enabled" in XWiki.User as part of https://jira.xwiki.org/browse/XWIKI-12654 to distinguish between inactive users (who have not confirm their registration with the token sent by email), and disabled users (who are deactivated by an admin, or by a security mechanism).
Now as Marius noticed those two properties are quite redundant, especially when you want to know which users are really active. So it introduces unnecessary complexity and we might even need to change existing extension to check enabled users (cf the last comments on XWIKI-12564).
So before doing those changes, I propose to fix immediately the issue by removing that newly introduced property and by introducing a new property only for assessing that users' email are checked.
Then we will only have to check "active" property to check if a user is active or not, and we could rely on it to set them enabled or disabled in the admin. The email_check property would be used only for the check email mechanism, so it will avoid any confusion in the semantic.
WDYT? Simon
-- Simon Urli Software Engineer at XWiki SAS [email protected] More about us at http://www.xwiki.com
On 22/08/2019 18:12, Thomas Mortagne wrote:
+1 never been a big fan of the duplicate. Would still be better to have a migration in case someone used the new disabled property to avoid bad surprises with security
Yes that's the plan, see what I said yesterday on the chat: I guess we could change that now but we might need a migration to do it properly: 1. Add the new "email checked" property to users set to false 2. for user "active", set this property to true, and leave the property to false for user inactive 3. for user disabled, switch active to inactive 4. remove the property "enabled" from users
Le jeu. 22 août 2019 à 16:01, Simon Urli <[email protected]> a écrit :
Hi everyone,
I recently (in XWiki 11.6RC1) introduced a new property "enabled" in XWiki.User as part of https://jira.xwiki.org/browse/XWIKI-12654 to distinguish between inactive users (who have not confirm their registration with the token sent by email), and disabled users (who are deactivated by an admin, or by a security mechanism).
Now as Marius noticed those two properties are quite redundant, especially when you want to know which users are really active. So it introduces unnecessary complexity and we might even need to change existing extension to check enabled users (cf the last comments on XWIKI-12564).
So before doing those changes, I propose to fix immediately the issue by removing that newly introduced property and by introducing a new property only for assessing that users' email are checked.
Then we will only have to check "active" property to check if a user is active or not, and we could rely on it to set them enabled or disabled in the admin. The email_check property would be used only for the check email mechanism, so it will avoid any confusion in the semantic.
WDYT? Simon
-- Simon Urli Software Engineer at XWiki SAS [email protected] More about us at http://www.xwiki.com
-- Simon Urli Software Engineer at XWiki SAS [email protected] More about us at http://www.xwiki.com
Hello Simon, while writing GPDR-compliant “technical organisation’s measures”, I’ve been insertion a statement that says that users who do not respond to an actualisation wish of the terms-of-conditions are automatically erased. The reason this is needed lies in the fact that an explicit agreement is always needed to any change in the data-privacy-policy as long as the user-profile contains personal information (generally, it does). As a result, it seems to me that one of these fields should be a date: “last activated” or something last this. Per default, we’d just make sure that this date is not the date zero. An authenticator that a would enable a wiki to be GPDR compliant with TOS and privacy notices would then check that the last-activated is later than the last modification date of these documents. I entirely agree that a second property stating that a user is disabled because his profile looks to be spam is a necessary thing. Here, I do not see a date requirement. thanks Paul On 22 Aug 2019, at 16:01, Simon Urli wrote:
Hi everyone,
I recently (in XWiki 11.6RC1) introduced a new property "enabled" in XWiki.User as part of https://jira.xwiki.org/browse/XWIKI-12654 to distinguish between inactive users (who have not confirm their registration with the token sent by email), and disabled users (who are deactivated by an admin, or by a security mechanism).
Now as Marius noticed those two properties are quite redundant, especially when you want to know which users are really active. So it introduces unnecessary complexity and we might even need to change existing extension to check enabled users (cf the last comments on XWIKI-12564).
So before doing those changes, I propose to fix immediately the issue by removing that newly introduced property and by introducing a new property only for assessing that users' email are checked.
Then we will only have to check "active" property to check if a user is active or not, and we could rely on it to set them enabled or disabled in the admin. The email_check property would be used only for the check email mechanism, so it will avoid any confusion in the semantic.
WDYT? Simon
-- Simon Urli Software Engineer at XWiki SAS [email protected] More about us at http://www.xwiki.com
Hi Paul, On 22/08/2019 21:23, Paul Libbrecht wrote:
Hello Simon,
while writing GPDR-compliant “technical organisation’s measures”, I’ve been insertion a statement that says that users who do not respond to an actualisation wish of the terms-of-conditions are automatically erased. The reason this is needed lies in the fact that an explicit agreement is always needed to any change in the data-privacy-policy as long as the user-profile contains personal information (generally, it does).
As a result, it seems to me that one of these fields should be a date: “last activated” or something last this. Per default, we’d just make sure that this date is not the date zero. An authenticator that a would enable a wiki to be GPDR compliant with TOS and privacy notices would then check that the last-activated is later than the last modification date of these documents.
I entirely agree that a second property stating that a user is disabled because his profile looks to be spam is a necessary thing. Here, I do not see a date requirement.
IMO here you are talking about a new usecase that we don't currently handle in XWiki. This proposal was about modifying the behaviour of two already existing usecases. So I wouldn't add the property you propose as part of this work, since I don't really need it here. Now I don't really see the problem of adding the new date property you propose on XWiki.Users as part of a new feature or an improvment. It's just not the scope of this proposal. Simon
thanks
Paul
On 22 Aug 2019, at 16:01, Simon Urli wrote:
Hi everyone,
I recently (in XWiki 11.6RC1) introduced a new property "enabled" in XWiki.User as part of https://jira.xwiki.org/browse/XWIKI-12654 to distinguish between inactive users (who have not confirm their registration with the token sent by email), and disabled users (who are deactivated by an admin, or by a security mechanism).
Now as Marius noticed those two properties are quite redundant, especially when you want to know which users are really active. So it introduces unnecessary complexity and we might even need to change existing extension to check enabled users (cf the last comments on XWIKI-12564).
So before doing those changes, I propose to fix immediately the issue by removing that newly introduced property and by introducing a new property only for assessing that users' email are checked.
Then we will only have to check "active" property to check if a user is active or not, and we could rely on it to set them enabled or disabled in the admin. The email_check property would be used only for the check email mechanism, so it will avoid any confusion in the semantic.
WDYT? Simon
-- Simon Urli Software Engineer at XWiki SAS [email protected] More about us at http://www.xwiki.com
-- Simon Urli Software Engineer at XWiki SAS [email protected] More about us at http://www.xwiki.com
On 23 Aug 2019, at 09:19, Simon Urli <[email protected]> wrote:
Hi Paul,
On 22/08/2019 21:23, Paul Libbrecht wrote:
Hello Simon, while writing GPDR-compliant “technical organisation’s measures”, I’ve been insertion a statement that says that users who do not respond to an actualisation wish of the terms-of-conditions are automatically erased. The reason this is needed lies in the fact that an explicit agreement is always needed to any change in the data-privacy-policy as long as the user-profile contains personal information (generally, it does). As a result, it seems to me that one of these fields should be a date: “last activated” or something last this. Per default, we’d just make sure that this date is not the date zero. An authenticator that a would enable a wiki to be GPDR compliant with TOS and privacy notices would then check that the last-activated is later than the last modification date of these documents. I entirely agree that a second property stating that a user is disabled because his profile looks to be spam is a necessary thing. Here, I do not see a date requirement.
IMO here you are talking about a new usecase that we don't currently handle in XWiki. This proposal was about modifying the behaviour of two already existing usecases. So I wouldn't add the property you propose as part of this work, since I don't really need it here.
Now I don't really see the problem of adding the new date property you propose on XWiki.Users as part of a new feature or an improvment. It's just not the scope of this proposal.
Thanks a lot Paul for mentioning this. I find it very interesting and important to mention since it could have had impacts on our solution. From what I understand, Simon is saying that what he’s planned goes in the direction you mentioned and will be compatible with it when we add it in the future. Would be great to record this in a JIRA for future work! Thanks -Vincent
Simon
thanks Paul On 22 Aug 2019, at 16:01, Simon Urli wrote:
Hi everyone,
I recently (in XWiki 11.6RC1) introduced a new property "enabled" in XWiki.User as part of https://jira.xwiki.org/browse/XWIKI-12654 to distinguish between inactive users (who have not confirm their registration with the token sent by email), and disabled users (who are deactivated by an admin, or by a security mechanism).
Now as Marius noticed those two properties are quite redundant, especially when you want to know which users are really active. So it introduces unnecessary complexity and we might even need to change existing extension to check enabled users (cf the last comments on XWIKI-12564).
So before doing those changes, I propose to fix immediately the issue by removing that newly introduced property and by introducing a new property only for assessing that users' email are checked.
Then we will only have to check "active" property to check if a user is active or not, and we could rely on it to set them enabled or disabled in the admin. The email_check property would be used only for the check email mechanism, so it will avoid any confusion in the semantic.
WDYT? Simon
-- Simon Urli Software Engineer at XWiki SAS [email protected] More about us at http://www.xwiki.com
-- Simon Urli Software Engineer at XWiki SAS [email protected] More about us at http://www.xwiki.com
+1 Thanks, Marius On Thu, Aug 22, 2019 at 5:01 PM Simon Urli <[email protected]> wrote:
Hi everyone,
I recently (in XWiki 11.6RC1) introduced a new property "enabled" in XWiki.User as part of https://jira.xwiki.org/browse/XWIKI-12654 to distinguish between inactive users (who have not confirm their registration with the token sent by email), and disabled users (who are deactivated by an admin, or by a security mechanism).
Now as Marius noticed those two properties are quite redundant, especially when you want to know which users are really active. So it introduces unnecessary complexity and we might even need to change existing extension to check enabled users (cf the last comments on XWIKI-12564).
So before doing those changes, I propose to fix immediately the issue by removing that newly introduced property and by introducing a new property only for assessing that users' email are checked.
Then we will only have to check "active" property to check if a user is active or not, and we could rely on it to set them enabled or disabled in the admin. The email_check property would be used only for the check email mechanism, so it will avoid any confusion in the semantic.
WDYT? Simon
-- Simon Urli Software Engineer at XWiki SAS [email protected] More about us at http://www.xwiki.com
participants (5)
-
Marius Dumitru Florea -
Paul Libbrecht -
Simon Urli -
Thomas Mortagne -
Vincent Massol