Social questions: Forum / dynamic group / Wall / Front-end access-control

Hello

I’ve developed quite a few projects on evolution, yet - first time posting on these wires, so i’d start with a big thank you for the efforts and works of this community (and it’s founders). It’s a well built framework which allows rapid creative coding. it’s simply fun to work with.

I am currently in the initial stage of developing a social network (private). I have tested the other options (mainly - elgg, buddypress,etc..), my concussion is they are all in transition now. (evo->revo,elgg 1.6->1.8->2.0, etc...). Although bare bone feature-less and still in beta - Revolution looks fitting and most future-ready.
My revolution-tests are very good until now, making some simply social snippets (add friend, like, etc..) which proved revo is very flexible and ready for whatever you throw at it (although it’s learning curve, xPDO is great,really..).
I am impressed.

There are some features I am still not clear of, I would be thankful if you could share your knowledge on that.

1. Forums
Our mandatory-features-list is quite simple (fixed forums,email notifications,moderation,comments) and looks/acts more like a shared blog then a developers-forum... I have just seen ’discuss’ vimeo.com/7045942 (very nice music in the background, ah?)
has anyone uses ’discuss’ in production already?


single-sign on, user provisioning and activity stream, are good enough issues to stay within the modx domain and not integrate external forum. but, if i understand xPDO correctly, I can also fully integrate external tables, even be able to do ->innerJoin between 3rdParty & modx tables ? and then send that content to placeholders to be used in modx templates ??
as it seem that would make 3rd party forums integration much simpler (activity stream, modx templating for forum posts). and in general - that would mean very rapid integrations to whatever. (collecting and managing the data all via modx). did I get it right about xPDO, or am i a bit too optimistic ?


2. Dynamic user group.
In revo - user groups are static lists
It seems to me that dynamic groups are needed. (i.e. group’s members is a query)
I want to control resource access or other membership-check, based on user’s attribute. for example, user can be member of multiple industries (fixed tags, which should be in a new schema, extending modUser). i would like those tag(s) to act as usergroup - dynamic usergroup (same concept exists in the ldap world).
Kind of @BINDING, query that defines the usergroup’s members list.
of course, this is not a stopper, as it’s possible to add logic layer on top in snippets, but I suggest this enhancement as I see it over and over. Much logic in revo uses usergroups - that’s great, but it seems that "usergroup" itself is limited, should be abstract in the "spirit of modx" .
can a usergroup be dynamic? did i miss a hook waiting for me already in the api/plugin?
(running on svn 6103)


3. Public vs. Members zone
two different contexts is overkill for that? the docs i found around are not so clear on that.
resources and elements is still possible between contexts? it might be simpler to go the "membership group" way, in one context, but it looked to me like context can do more (security, hard separation, etc..)


4. Front-end content editing
profile editing, account control, blog post, etc.. all front-end. jQuery+modx allow nice features.
Ideally, I would like granular control over both read and write permissions, which i understand will appear around revo 2.1, in some way.
it seems "Access Policy-> permissions" has some functionality that might be of use for me, but the picture isn’t clear from the docs.
In addition - a role can not be associated with a user, only with a usergroup (see above #2), yea?

It might be simpler to resolve it "old-fashion" way, using my own permission-checks around my snippets and form generator. For example: allow page editing functions based on createdBy (resource owner) and group-membership (moderators).
(elgg should be noted as powerful in this subject, you build one single form in which each field has it’s own access-control. the form is rendered based on that. but still - it lacks write permissions, which will arrive only in elgg 2.0 )



Thanks in advance for your time,
oori

Quote from: oori at Nov 26, 2009, 08:10 PM

1. Forums
Our mandatory-features-list is quite simple (fixed forums,email notifications,moderation,comments) and looks/acts more like a shared blog then a developers-forum... I have just seen ’discuss’ vimeo.com/7045942 (very nice music in the background, ah?)
has anyone uses ’discuss’ in production already?

Discuss is still in early alpha and will most likely not be ready before late Spring 2010.

single-sign on, user provisioning and activity stream, are good enough issues to stay within the modx domain and not integrate external forum. but, if i understand xPDO correctly, I can also fully integrate external tables, even be able to do ->innerJoin between 3rdParty & modx tables ? and then send that content to placeholders to be used in modx templates ??

Yes, via snippets. Most of the dynamic parts of the modxcms.com site are done this way.

as it seem that would make 3rd party forums integration much simpler (activity stream, modx templating for forum posts). and in general - that would mean very rapid integrations to whatever. (collecting and managing the data all via modx). did I get it right about xPDO, or am i a bit too optimistic ?

No, you are correct. However, there are many approaches to SSO integration of 3rd party forums - some forums, like SMF, are not coded well enough to make this possible. Some, however, are. It will depend on which forum you are wanting.

In revo - user groups are static lists
It seems to me that dynamic groups are needed. (i.e. group’s members is a query)

I’m not sure what you mean by "dynamic groups."

I want to control resource access or other membership-check, based on user’s attribute. for example, user can be member of multiple industries (fixed tags, which should be in a new schema, extending modUser). i would like those tag(s) to act as usergroup - dynamic usergroup (same concept exists in the ldap world).

Wait a minute - why are you adding a whole new attribute? Why not just have your script or whatever just assign the users to a user group?

I’m not totally sure the point of all of this extra complexity. Can you give an example or case scenario?

of course, this is not a stopper, as it’s possible to add logic layer on top in snippets, but I suggest this enhancement as I see it over and over. Much logic in revo uses usergroups - that’s great, but it seems that "usergroup" itself is limited, should be abstract in the "spirit of modx" .

Feel free to post a feature request in JIRA: http://bugs.modxcms.com/ - I can tell you though that something of that nature wont be looked at for core integration until at least 2.1.

3. Public vs. Members zone
two different contexts is overkill for that? the docs i found around are not so clear on that. it might be simpler to go the "membership group" way, in one context, but it looked to me like context can do more (security, hard separation, etc..)

Maybe not "overkill", no, but you could do this with just a Resource Group, similar to how you’d do it in Evo. That said, Contexts would allow you different functionality, yes, such as a custom unauthorized page for that context.

resources and elements is still possible between contexts?

Yes.

4. Front-end content editing
profile editing, account control, blog post, etc.. all front-end. jQuery+modx allow nice features.
Ideally, I would like granular control over both read and write permissions, which i understand will appear around revo 2.1, in some way.

"Granular" Access-Based Access Controls (ABAC) are already built into Revo as-is; however, they only apply to Contexts or User Groups, currently. You can add specific Permissions to Policies, which are then assigned via Access Controls to Contexts/User Groups.

In addition - a role can not be associated with a user, only with a usergroup (see above #2), yea?

Correct.

It might be simpler to resolve it "old-fashion" way, using my own permission-checks around my snippets and form generator. For example: allow page editing functions based on createdBy (resource owner) and group-membership (moderators).

You can do it however you like.