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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
