Bug #20557

Notification emails are send to assigned users only, not to groups

Added by Matthias Stübner almost 4 years ago. Updated about 2 years ago.

Status:Closed Start date:2009-06-03
Priority:Should have Due date:
Assignee:Benjamin Mack % Done:

0%

Category:-
Target version:-
TYPO3 Version:4.2 PHP Version:
Votes: 0

Description

The change notifications in a workspace are not send to user groups assigned to different roles (member & reviewer), but to users that are directly assigned by user.

That leads to, that users who shall receive notifications, must be assigned directly, even that they are members of assigned groups. So users get assigned twice, what is not straight forward.

Also it is a known rule in IT that rights are not given to users but groups, for better maintainability.

The assigned patch changes "notifyStageChange_getEmails()" to collect users and their email adresses from assigned groups too and sends them notifications.

Assigned patch has been made agains v4trunk
(issue imported from #M11255)

class.t3lib_tcemain.patch (689 Bytes) Administrator Admin, 2009-06-03 12:02

0011255_notification-emails-to-groups.diff (802 Bytes) Administrator Admin, 2009-08-01 11:57


Related issues

related to Workspaces & Versioning - Bug #17569: No notification mails will be sent on using user groups Under Review 2007-08-30

History

Updated by Andreas Wolf almost 4 years ago

I adjusted the patch to latest trunk and posted it to the core list.

Updated by Georg Ringer over 3 years ago

nice idea but this won't work in 95% of the cases because if you are using workspaces, the website will be a bigger one and I bet you will have more than 1 usergroup assigned to users.

so getting the users with a query like "AND usergroup = 3" won't work with usergroups set like "1,4,3".

furthermore recursive usergroups are not checked.

IMO t3lib_BEfunc::getRecordsByField cant be used because it doesn't make too much sense enhaning this with the listquery

what do you think?

Updated by Tobias Liebig over 3 years ago

Hey Georg,

- did you test the patch or reviewed it in context of the whole t3lib_tcemain class?
i think it worked fine with multiple usergroups and also when you mix up groups and users.
Or didn't i get you right?

- recursive usergroups
your right. the users should be collected recursively

- t3lib_BEfunc::getRecordsByField
maybe we can save some sql querys, when we dont use t3lib_BEfunc::getRecordsByField within the for loop, but collect all be_groups uids and then do a single query afterwards.
Is that your point?

btw t3lib_BEfunc::getRecordsByField can be refactored to use exec_SELECTgetRows, but that's another issue

Updated by Georg Ringer over 3 years ago

getRecordfsByField uses
---------
$theField.'='.$GLOBALS['TYPO3_DB']->fullQuoteStr($theValue, $theTable).
-------

so it can't work to get a user whose usergroup is "1,2,4,5"

I tested it too.

it is working if you are using a code like this
---------------
if ($table === 'be_groups') {
$res = $GLOBALS['TYPO3_DB']->exec_SELECTquery('*', 'be_users', 'pid=0 AND '.$GLOBALS['TYPO3_DB']->listQuery('usergroup',intval($id),'be_users').t3lib_BEfunc::deleteClause('be_users'));
while($row = $GLOBALS['TYPO3_DB']->sql_fetch_assoc($res)) {
if (strlen(trim($row['email']))) {
$emails[$row['uid']] = $row['email'];
}
}
} elseif ($table==='be_users' || $noTablePrefix) {
----------

which I took from the related bug (http://bugs.typo3.org/view.php?id=6239) but I guess it could also be improved by adding "email != ''" to the where clause (recursive collection is still missing but IMO there is a real need to get this into a seperate function)

Updated by Tobias Liebig over 3 years ago

Now i get it, thanks. You're completely right!

Updated by Bjoern Jacob over 3 years ago

IMHO opinion this is a very important feature. I've got two bigger installations with workspaces. Quite often people ask me why notification emails aren't send to them. The answer is quite easy: they've forgotten to add the new user to the appropriate fields. So what do you think? When do we get this feature?

Updated by Georg Ringer over 3 years ago

IMO this wont go into 4.3.0 because of feature freeze, but you fix it yourself at any time

Updated by Bjoern Jacob over 3 years ago

Yes that's right. Do the supplied patches respect the comments you've made? If yes I can test the patches...

Updated by Benjamin Mack about 2 years ago

  • Status changed from Accepted to Closed
  • Target version deleted (0)

Also available in: Atom PDF