All, Would this not be an XWiki best practice issue in user management? How does a generic XWiki ban a spammer or bad actor from returning with the same ID or e-mail? We created the concept of "e-mail not deliverable" to deal with bounces and bad e-mails and to omit those users from system generated e-mails. This too would seem to be a generic XWiki challenge. Joshua Marks CTO Curriki: The Global Education and Learning Community [email protected] www.curriki.org US 831-685-3511 I welcome you to become a member of the Curriki community, to follow us on Twitter and to say hello on our blog, Facebook and LinkedIn communities. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Sergiu Dumitriu Sent: Wednesday, October 03, 2012 9:57 AM To: XWiki Developers Subject: Re: [xwiki-devs] Mark user as deactivated/spammer On 10/03/2012 11:43 AM, Felix AtCurriki wrote:
Hi all,
At Curriki we currently work on a small tool which allows us to search users and apply changes to their "active/inactive" and "email_undeliverable" values easily without the need of editing the user objects manually.
That gives us the following combinations for user states which are already in use (e.g. in the registration process):
- User state: Active Values: (active:"Active", email_undeliverable:No) - User state: Inactive Values: (active:"Inactive", email_undeliverable:Yes) - The user needs to revalidate his email address
Now if we want users to be marked as deactivated/spammers do you think would it be a good way to define an additional user state by expressing it through boolean combinations like this:
- User state: Deactivated/Spammer Values: (active:"Inactive", email_undeliverable:*No*)
Or do you think it would it be better to add an entry to the choices of the "active" value in the user object which explicitly says "deactivated" or "spammer".
Or do you have any other best practice solutions?
I prefer to keep the semantics of fields pure, so I don't agree that the user state should be computed from the different combinations of the other two fields. Add a new field user_state to the class and explicitly put the state in there. This is more flexible and allows for future new states. Suggested field type: static list. -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs