Customizing menus, enable/disable features, other modifications etc

[mortench]

First of all congrats for a excellent project! Works fine and the
sample looks great too :-)

I am trying to evaluate if I can use community engine for a project of
mine. For this I need to do quite some customization which I am trying
to evaluate the complexity of. I already looked what can be done by a
custom "application.yml" and it seems a bit limited. F.x. I could see
no way to turn off a specific category in the menu?

Examples of the things I would like to customize / change:
1) Modify menus - remove some menu options, rename and localize others
+ add some new ones. I guess this can be done by providing my own
theme but are there easier ways ?
2) Restrict blogging in all or selected categories to "experts" and
administrators (the way for "normal" users to post things would be in
the forum).
3) Remove birth date/month (but not year) from the login forms -
storing full birth dates is not acceptable due to privacy concerns
(promotes identity thefts etc).
4) Adding openID support (I already have some OpenID code working for
an existing site which I could modify and contribute to the community
engine project).
5) Barebones user registration (just email+password OR openid) without
login name or req. email confirmation code activation process etc.
6) Allow administrators to tag users such as experts according to
expertise.
7) Restrict creating of new tags to experts and/or administrators (to
avoid chaos of tags).
8) Customizing when "featured experts" appear f.x. according to some
match between posting tags and experts.
9) Impl. various features to combat spam incl. making it difficult to
register for a robot + ability for users to makr posts as spam
(notifies administrators) + ability for an admin to easily delete all
posts of a specific (spam) user etc.
10) More privacy- restrict users ability to see details of other users
by default.
11) Support large number of forums by putting them into sections/
categories.
etc.

Clearly all these things can be changed by overriding controllers,
views, models but that would be a lot of extra work and I would have
to fight to keep my code aligned wit the community engine in the
future.

An alternative approach - which I would prefer -would be to help with
a more flexible configuration system where features/menus in
particular can be enabled/disabled easily. The rest of the stuff could
just be added to the community engine code provided they are "in
scope" as far as the project owners see it? Interested in such
contributions? Any guesses regarding added complexity of such a
general solution?

Cheers,
Morten

[Bryan Kearney]

mortench wrote:
> First of all congrats for a excellent project! Works fine and the
> sample looks great too :-)
>
> I am trying to evaluate if I can use community engine for a project of
> mine. For this I need to do quite some customization which I am trying
> to evaluate the complexity of. I already looked what can be done by a
> custom "application.yml" and it seems a bit limited. F.x. I could see
> no way to turn off a specific category in the menu?
>
> Examples of the things I would like to customize / change:
> 1) Modify menus - remove some menu options, rename and localize others
> + add some new ones. I guess this can be done by providing my own
> theme but are there easier ways ?

Many of the menu items are driven off of instances of Categories. Does
changing that list help you? Look at migration 21 for the plugin.

> 2) Restrict blogging in all or selected categories to "experts" and
> administrators (the way for "normal" users to post things would be in
> the forum).
> 3) Remove birth date/month (but not year) from the login forms -
> storing full birth dates is not acceptable due to privacy concerns
> (promotes identity thefts etc).

Interesting, on facebook it is the other way around. However.. I agree
it would be nice to show one or the other.

> 4) Adding openID support (I already have some OpenID code working for
> an existing site which I could modify and contribute to the community
> engine project).

+1

I will let Bruno speak to that. But.. fork the project in github and
give it a wirl.

-- bk

[mortench]

> > Examples of the things I would like to customize / change:
> > 1) Modify menus - remove some menu options, rename and localize others
> > + add some new ones. I guess this can be done by providing my own
> > theme but are there easier ways ?
>
> Many of the menu items are driven off of instances of Categories. Does
> changing that list help you? Look at migration 21 for the plugin.

Thanks for the pointer. I tried to delete a row and it caused the menu
item to disappear. Good but a bit too hardcoded for my taste. Can a
migration be overridden or would I have to create a migration myself
to delete and rename categories? Otherwise, I guess one slightly
better way to customize this would be declare an array of categories
in application yml and let the plugin's migration do a foreach on it
instead.

> > 2) Restrict blogging in all or selected categories to "experts" and
> > administrators (the way for "normal" users to post things would be in
> > the forum).
> > 3) Remove birth date/month (but not year) from the login forms -
> > storing full birth dates is not acceptable due to privacy concerns
> > (promotes identity thefts etc).
>
> Interesting, on facebook it is the other way around. However.. I agree
> it would be nice to show one or the other.

Good to hear you would like such an option. I guess the user model
could be changed to that explict contribution/posting rights can be
specified.

> I will let Bruno speak to that. But.. fork the project in github and
> give it a wirl.

I think it is smartest to wait until the localized version is ready
and I am sure that I get positive feedback from Bruno also about my
proposed changes (I don't want to "fork" anything permanently so I
need to be sure my proposed changes would be "in scope").

Thanks for your reply,
Morten

[Bruno Bornsztein]

Ok, here goes...

Examples of the things I would like to customize / change:
1) Modify menus - remove some menu options, rename and localize others
+ add some new ones. I guess this can be done by providing my own
theme but are there easier ways ?

When logged in as an admin user, you can go to /categories to edit the categories (delete, change the names, change the text that's displayed in the menu, etc.).  

I agree that the default categories shouldn't be hardcoded in that migration... we should take that out.

 

2) Restrict blogging in all or selected categories to "experts" and
administrators (the way for "normal" users to post things would be in
the forum).

This isn't something I need, but it'd probably just be a question of making some tweaks to the category model to set which roles can post. I guess you'd add a column to Category called 'minimum_role_for_posting', which would have the role_id of the lowest role needed to post in that category, or nil if everyone can post. 

 

3) Remove birth date/month (but not year) from the login forms -
storing full birth dates is not acceptable due to privacy concerns
(promotes identity thefts etc).

I guess I've never had any concerns expressed to me about storing full birthdates (especially since they're not displayed on the site). This is just a question of overriding the user model and the users/new.html.haml template in your app. 

 

4) Adding openID support (I already have some OpenID code working for
an existing site which I could modify and contribute to the community
engine project).

+1

 

5) Barebones user registration (just email+password OR openid) without
login name or req. email confirmation code activation process etc.

I'm lukewarm on this. I think the e-mail confirmation/activation process is pretty standard, and if you want to eliminate it, that should be something that happens in your app (override the model/controller), not in core. However, if it can be done easily with an application.yml setting, I'd consider including it.

6) Allow administrators to tag users such as experts according to
expertise. 

7) Restrict creating of new tags to experts and/or administrators (to
avoid chaos of tags).

Sounds like these are particular to your application. I'm not sure this belongs in core.

8) Customizing when "featured experts" appear f.x. according to some
match between posting tags and experts.

I don't quite follow this one. Can you explain further?

 

9) Impl. various features to combat spam incl. making it difficult to
register for a robot + ability for users to makr posts as spam
(notifies administrators) + ability for an admin to easily delete all
posts of a specific (spam) user etc.

+1 to spam fighting.

Admin can already delete all posts by a user by simply deleting that user. Admin can also access any users 'posts/manage' page, which should probably have a bulk delete function anyway. +1 to bulk delete on 'posts/manage'

 

10) More privacy- restrict users ability to see details of other users
by default.

-1 CE doesn't collect anything very private in the first place. Birthday is not shown on the profile. Location is optional, as is 'about me'. What else did you have in mind?

 

11) Support large number of forums by putting them into sections/
categories.
etc.

Not something I need badly, but I'm ok with it (I assume you mean something like ForumCategory?)

 

 

An alternative approach - which I would prefer -would be to help with
a more flexible configuration system where features/menus in
particular can be enabled/disabled easily.

-1. I've used complex 'menu building' systems (Joomla) and hate them. I'd rather just leave it at customizable Category names and the ability to easily override the 'header.html.haml' template.

By the way... thanks a lot for taking an interest and suggesting some good improvements. If I seem a bit hesitant, it's not because I don't appreciate the help, but because I want to be very careful to keep the plugin from getting bloated.

Thanks!

Bruno 

[mortench]

On Jul 22, 7:59 pm, "Bruno Bornsztein" <bruno.bornszt...@gmail.com>
wrote:
> Ok, here goes...

> When logged in as an admin user, you can go to /categories to edit the
> categories (delete, change the names, change the text that's displayed in
> the menu, etc.).

Thanks did not notice that.

> I agree that the default categories shouldn't be hardcoded in that
> migration... we should take that out.

Ok. I think I would prefer to create a default array in
application.yml where the default categories are defined. Maybe we
could make non-category menu items such as "Discussion" and "Profile"
optional as well.

> > 2) Restrict blogging in all or selected categories to "experts" and
> > administrators (the way for "normal" users to post things would be in
> > the forum).
>
> This isn't something I need, but it'd probably just be a question of making
> some tweaks to the category model to set which roles can post. I guess you'd
> add a column to Category called 'minimum_role_for_posting', which would have
> the role_id of the lowest role needed to post in that category, or nil if
> everyone can post.

ok.

> > 3) Remove birth date/month (but not year) from the login forms -
> > storing full birth dates is not acceptable due to privacy concerns
> > (promotes identity thefts etc).
>
> I guess I've never had any concerns expressed to me about storing full
> birthdates (especially since they're not displayed on the site).

But what about the risk of exposing the birthdates by mistake or if a
hacker gets to them?

See here for a interesting real problem with birthdates in Facebook:
http://www.itworld.com/news/53676/facebook-bug-leaks-members-birthday-data

I don't need full birthdates (just year) and don't want to expose my
users or business to risks in this area.

> This is
> just a question of overriding the user model and the users/new.html.haml
> template in your app.

Or it could be configurable?

> > 4) Adding openID support (I already have some OpenID code working for
> > an existing site which I could modify and contribute to the community
> > engine project).
>
> +1

Fine. The biggest problem is how to redesign the login screen so users
that don't know openid does not get confused. I would also need to
make changes to user model and migrations etc.

> > 5) Barebones user registration (just email+password OR openid) without
> > login name or req. email confirmation code activation process etc.
>
> I'm lukewarm on this. I think the e-mail confirmation/activation process is
> pretty standard, and if you want to eliminate it, that should be something
> that happens in your app (override the model/controller), not in core.

I know the activation process is pretty standard but I would like to
offer a
second dead-simple process as well. Besides I would need to change the
activation
process for OpenID support anyway. If this feature does not belong in
the core plugin
maybe I can provide some hook that makes it easier to implement (I
don't like to copy the User model as I would effectively be branching
parts of the plugin).

> However, if it can be done easily with an application.yml setting, I'd
> consider including it.

ok.

> 6) Allow administrators to tag users such as experts according to
>
> > expertise.
>
> 7) Restrict creating of new tags to experts and/or administrators (to
>
> > avoid chaos of tags).
>
> Sounds like these are particular to your application. I'm not sure this
> belongs in core.

I think administrative tagging of users could be useful for others
too. For your own site uncooped.com, administrative tagging of users
could be used to group featured writers into featured writers about
f.x. bycycles and featured writers about emergency-aid etc. These
groups of writers could then be presented in different sections of the
site.

As for creation of tags it is impossible to avoid complete tag-clutter
with the current approach. A fixed taxonomy or a fixed set of tags is
better in some cases such as expert sites. I think this is a pretty
general use case and I would like to make this configurable.

> 8) Customizing when "featured experts" appear f.x. according to some
>
> > match between posting tags and experts.
>
> I don't quite follow this one. Can you explain further?

Basically this is again about being able to tag (attach metadata) to
selected users. I think it is better that I show it to you when I have
something finished as it is a bit hard to explain.

> > 9) Impl. various features to combat spam incl. making it difficult to
> > register for a robot + ability for users to makr posts as spam
> > (notifies administrators) + ability for an admin to easily delete all
> > posts of a specific (spam) user etc.
>
> +1 to spam fighting.
> Admin can already delete all posts by a user by simply deleting that user.
> Admin can also access any users 'posts/manage' page, which should probably
> have a bulk delete function anyway. +1 to bulk delete on 'posts/manage'

Good. I will think about what else can be done. It is a bit hard to do
something well
as even google's anti-spam get broken. On the other hand if we make
something simple yet unusual there is chance that spammers will leave
us alone :-)

> > 10) More privacy- restrict users ability to see details of other users
> > by default.
>
> -1 CE doesn't collect anything very private in the first place. Birthday is
> not shown on the profile. Location is optional, as is 'about me'. What else
> did you have in mind?

I am not even sure being able to see the list of other users is
appropriate in my case. Maybe
experts users only. I am thinking about

> > 11) Support large number of forums by putting them into sections/
> > categories.
> > etc.
>
> Not something I need badly, but I'm ok with it (I assume you mean something
> like ForumCategory?)

Maybe. Do you have a link ?

> > An alternative approach - which I would prefer -would be to help with
> > a more flexible configuration system where features/menus in
> > particular can be enabled/disabled easily.
>
> -1. I've used complex 'menu building' systems (Joomla) and hate them. I'd
> rather just leave it at customizable Category names and the ability to
> easily override the 'header.html.haml' template.

Ok. I can live with that (although I might show you a very simple
array based
way to configure a "standard" in application.yml so you can decide on
something concrete).

> By the way... thanks a lot for taking an interest and suggesting some good
> improvements. If I seem a bit hesitant, it's not because I don't appreciate
> the help, but because I want to be very careful to keep the plugin from
> getting bloated.

Thanks. No problem at all. The system I (we) are developing has many
things similar to community engine but also a few things which is
quite different. The trick is to add our features without forking the
community engine but also without introducing unnecessary complexity
or having the risk of adding stuff that the other developers deem out
of scope?

P.S. What features do you guys have planned or on the wishlist? Maybe
we could identify overlaps which would be good :-)

Cheers,
Morten

[PAT CHEUNG]

> +1 to spam fighting.
> Admin can already delete all posts by a user by simply deleting that user.
> Admin can also access any users 'posts/manage' page, which should probably
> have a bulk delete function anyway. +1 to bulk delete on 'posts/manage'

Good. I will think about what else can be done. It is a bit hard to do
something well
as even google's anti-spam get broken. On the other hand if we make
something simple yet unusual there is chance that spammers will leave
us alone :-)

Just to note... there are 2 major possible spam areas. Spam blog entries and spam comments. Is there a way to let each individual user control spam comments, and site admins control spam blogs? Maybe a solution like Akismet?

--
pat cheung
email: rapa...@gmail.com
blog: methink.com

[Bruno Bornsztein]

From my experience with Curbly, SPAM is not a huge issue. Yes, there are occasional spam posts, but you can assign as many moderators as you want (they have rights to delete any post).

I'm more concerned about some kind of flood control, so that in the event of a malicious spam attack, you wouldn't have to deal with deleting thousands of spam posts at once.

[mortench]

Good to hear that Curbly has not had any major spam problems. However,
I do think you have been lucky. Without a good anti-spam defence it is
only a question of time before your site could get flooded (especially
if they are getting really successful).

Some ideas of what I think could help:
1) Registering user IP addresses on signup/login and being able to
(temporarily) blacklist new user reg. based on IP - this could also
hit innocent users however.
2) Moderation - Need approval from administrator for the user's first
message only (good compromise I think) or even stricter for all
messages.
3) Allowing users to nominate something as spam. If enough users
nominate something as spam accept it as such (maybe on a provisional
basis). A smart solution may also be able to negate false spam
nominations (if that is indeed a problem) by keeping statistics of
which users nominate spam correctly/incorrectly etc.
4) Integrate an automated spam filter. Akismet is pretty good and
might be an option as earlier mentioned (it has a web API for it). It
is also possible to build such as system by hand using Naive Bayes
etc. but such a system needs training which is not trivial. There is
also the risks of false positives etc.
5) Building some custom system where there human user has to reply to
some random questions in order to sign up... With answers that a
computer can't easily automated or where the attacker at least has to
build a custom AI solution for the particular site (so the lazy
spammer will drop it). Variations of this is images with numbers/
letters, math/domain questions etc. None of which is really 100%
effective.

I think CommunityEngine should implement some of these measures and
not rely on any single method as none is 100% perfect. I would be
interested in contributing with some of the work. My interest is
mostly in the simpler methods 1 & 2.

/Morten

[alexnesbitt]

I have found that there is a dramatic difference in spam problems
between custom coded sites and those that use code used by a lot of
people, eg wordpress, phpbb etc. The popular code bases get attacked
because the spammers can scale their spam across lots of sites.

I personally think it wise to start thinking of lines of defense early
on and build them in as options that can be enabled.

I have found akismet to be very good and would recommend it for both
post and comment filtering.

I have also started using http://recaptcha.net/ and been very happy
with how easy it is to use and how well it works.

Alex

[Bruno Bornsztein]

I think CommunityEngine should implement some of these measures and
not rely on any single method as none is 100% perfect. I would be
interested in contributing with some of the work. My interest is
mostly in the simpler methods 1 & 2.

I like #2 - as long as it's a setting that can be switched on from application.yml.
Let me know if you make any progress on that one!
 

/Morten