Bug #20557
closed
Notification emails are send to assigned users only, not to groups
Added by Matthias Stübner over 15 years ago.
Updated almost 11 years ago.
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)
Files
I adjusted the patch to latest trunk and posted it to the core list.
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?
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
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)
Now i get it, thanks. You're completely right!
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?
IMO this wont go into 4.3.0 because of feature freeze, but you fix it yourself at any time
Yes that's right. Do the supplied patches respect the comments you've made? If yes I can test the patches...
- Status changed from Accepted to Closed
- Target version deleted (
0)
- Category set to Workspaces
- Project changed from 624 to TYPO3 Core
- Category changed from Workspaces to Workspaces
Also available in: Atom
PDF