Tuesday 04 December 2007 3:11:39 pm

Hello Georg,

Have you tried?
{def $logged_in_users = fetch("user", "logged_in_list")}

You have more info and a list of sort options on the following page:
http://ez.no/doc/ez_publish/technical_manual/3_10/reference/modules/user/fetch_functions/logged_in_list

Tuesday 04 December 2007 4:05:51 pm

Exact, sorry about that if misread your question.

It looks like you do need to create a custom fetch operator.

Thursday 06 March 2008 10:01:47 am

Felix: I'm not sure I agree that they should be automatically hidden.
And your patch looks like contains some errors (no file):

Index: .
===================================================================
--- . (revision 2250)
+++ . (working copy)

Wouldn't be more clean to have a attribute filter for activated/deactivated users?

eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom

Thursday 06 March 2008 11:47:52 pm

Hi all,
We discuss in our team a lot about this topic. To use a extended attributefilter was one possibility, but in our project we use a lot of other extendedattibutefilters. But you can't use 2 filters at the same time. The other thing was, to extend all fetches where Users should be include, was not acceptable. In our community site the searchresult includes users to.

Then we thougt about the kernel patch, to hide a usernode if it is disabled. So all fetches works fine :-).
And if you want to have a list of all users you can ignore the visibility.

I think for the normal ez setup where users are placed under node 5, our kernel patch has no affect, because visibility of usernode is not use. Only if you place the users in the contentree ( under node 2) we have this situation.

For example a spammer create a new login with bad words. The userobject ist placed under the public available CommunityUserGroup folder. Here the userobject should be only visible if it is enabled. And of course this SpamUserObject should be not found from any fetch in the communitysite.

I hope you can follow my thought.

@ André R. i will check the patches

http://www.jac-systeme.de - Developers united in eZ Publish: http://www.cjw-network.com

CJW Newsletter 1.0.0 released: http://projects.ez.no/cjw_newsletter

Friday 07 March 2008 3:50:13 am

There are more cases, where user accounts are in the content tree:

You have a mixed B2B shop and B2C corporate site:

They sell products via dealers to end costumers. Some of their dealers are for the end costumer (visible) some are only internal visible for the shop and the intranet, because they sell only to big companies (whole sale) or don't want to be listed and some are deactivated but still important for order history etc. so you can't delete them (what is most of the time not a good idea with user accounts, since a lot of objects loose the creator.

Anonymous see products (class) without price and all dealers (class with user account) listed expect of non end costumer and deactivated user.

dealers (class with user account) have login for shop, intranet and they are visible for anonymous, or not or deactivated, can edit their profile and children objects, which are special products (offer of the month, but without price with links on their shops) if visible. So you give them only edit access to their own user class (dealer) and their children, for product price and intranet. Clean story for eZ user rights.

When you now thing of search, then you need a solution with clear fetches:

Anonymous see dealers in search, with are activated and not whole sale and not deactivated.

Anonymous see products of the month of dealers in search, with are activated and not whole sale and not deactivated.

So even with Kristofs filter, you have them in search and everywhere, I think the easiest solution is to take the patch from Felix, make then invisible.

Greetings, ekke

http://www.coolscreen.de - Over 40 years of certified eZ Publish know-how: http://www.cjw-network.com
CJW Newsletter: http://projects.ez.no/cjw_newsletter - http://cjw-network.com/en/ez-publ...w-newsletter-multi-channel-marketing

Friday 07 March 2008 12:38:09 pm

Hi,

>> it could be a workflow event type, which creates the activation code, sends out the
>> activation e-mail and halts the work flow. When the account gets activated by the user,
>> the publish work flow continues.

This is a great idea. In addition to hinder the publishing the before the registration is completed, this solution would make it easier to add different ways of activation (e.g. by SMS).

Felix

Publlic Relations Manager
Greater Stavanger
www.greaterstavanger.com

Saturday 08 March 2008 5:12:10 am

Hi again,

IMHO a rewrite of the user-module is long over due. This because of:

- the need for flexibility in terms of workflow
- the need for different ways of handling activation (email, SMS etc)
- the need for different simplicity in the registration process
- the web2.0 role of the user, not only a subject of autherization but also as an social object

Felix

Publlic Relations Manager
Greater Stavanger
www.greaterstavanger.com