9 Oct
2012
9 Oct
'12
12:28 a.m.
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
jmarks(a)curriki.org
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: devs-bounces(a)xwiki.org [mailto:devs-bounces@xwiki.org] 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs