Category: Group

__This feature request was accidently submitted twice.__
__Please use only [item6469]__

See here:

https://dev.tiki.org/Newsletter#Roadmap

__Per user/group newsletter administration__ based on category permission or on object permission.
* It should (shall) be possible for specified groups to provide an own group-newsletter created by a superuser, which then could (shall) be administrated by one or more specified group members / group admins whilst the newsletter admin of one group cannot (shall not) administrate or alter the newsletter(s) of another group.
* This could be accomplished by adding to the code the opportunity to categorise newsletters and to add certain admin-permissions like tiki_p_batch_subscribe_email, tiki_p_send_newsletters, tiki_p_subscribe_email, tiki_p_subscribe_newsletters, tiki_p_view_newsletter, tiki_p_list_newsletters to the category permissions (not tiki_p_admin_newsletters)
* There should be a distinction between tiki_p_admin_newsletters which includes the permission to create a new newsletter and the now not (yet) existing tiki_p_admin_newsletter which would limit admin permissions to the specific newsletter.

See here:

https://dev.tiki.org/Newsletter#Roadmap

__Per user/group newsletter administration__ based on category permission or on object permission.
* It should (shall) be possible for specified groups to provide an own group-newsletter created by a superuser, which then could (shall) be administrated by one or more specified group members / group admins whilst the newsletter admin of one group cannot (shall not) administrate or alter the newsletter(s) of another group.
* This could be accomplished by adding to the code the opportunity to categorise newsletters and to add certain admin-permissions like tiki_p_batch_subscribe_email, tiki_p_send_newsletters, tiki_p_subscribe_email, tiki_p_subscribe_newsletters, tiki_p_view_newsletter, tiki_p_list_newsletters to the category permissions (not tiki_p_admin_newsletters)
* There should be a distinction between tiki_p_admin_newsletters which includes the permission to create a new newsletter and the now not (yet) existing tiki_p_admin_newsletter which would limit admin permissions to the specific newsletter.

{syntax type="tiki" editor="plain"}
In a Tiki 29 I use groups for member of the same team.
In a trackerA I set a group selector field1 to select from which group is a contact.
In a trackerB I have an itemlink field2 that display and link to the trackerA field1.

On a wiki page I display information on a plugin list from the trackerB.
The information is displayed but I can also see a feedback from the lib/core/Tracker/Field/GroupSelector.php, a warning on ther top of the page.

{CODE()}
} elseif (empty($includedGroups) && ! $perms->admin_trackers) {
// user not in any of the required groups, use the global default $group and warn
$defGroup = $group;
Feedback::warning(tr('User not in any of the required groups for GroupSelector field'));
{CODE}

For some reason displaying the tracker field2 is running this code and display an error where there is none.

https://doc.tiki.org/PluginGroup
When I am editing Wikipage text in the editor:
1.I first highlight all the text I want added to the security group.
2.I press the Group icon button to add all the text to the {GROUP( groups="Admins")}  text text {GROUP} code block.
3.I press Save.
4. It produces garbled plugin-code as follows:
 
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean vitae facilisis sem, eu facilisis ipsum. Integer tincidunt, nulla eget semper posuere, erat sapien ullamcorper lorem, ac tristique magna risus sit amet velit. Quisque id tortor eget nunc cursus fermentum. Donec vel ligula mi. Suspendisse justo ante, volutpat bibendum sodales at, feugiat sed felis. Proin a massa ac erat molestie condimentum. Curabitur egestas, ex quis dapibus sagittis, neque quam aliquam lectus, ut tincidunt orci justo et nibh. " data-plugin="group" data-syntax="

{GROUP( groups="Admins")}Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean vitae facilisis sem, eu facilisis ipsum. Integer tincidunt, nulla eget semper posuere, erat sapien ullamcorper lorem, ac tristique magna risus sit amet velit. Quisque id tortor eget nunc cursus fermentum. Donec vel ligula mi. Suspendisse justo ante, volutpat bibendum sodales at, feugiat sed felis. Proin a massa ac erat molestie condimentum. Curabitur egestas, ex quis dapibus sagittis, neque quam aliquam lectus, ut tincidunt orci justo et nibh. {GROUP}
" style="position:relative;display:inline-block;" unselectable="on">{img src="img/icons/wiki_plugin_edit.png"}
 
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean vitae facilisis sem, eu facilisis ipsum. Integer tincidunt, nulla eget semper posuere, erat sapien ullamcorper lorem, ac tristique magna risus sit amet velit. Quisque id tortor eget nunc cursus fermentum. Donec vel ligula mi. Suspendisse justo ante, volutpat bibendum sodales at, feugiat sed felis. Proin a massa ac erat molestie condimentum. Curabitur egestas, ex quis dapibus sagittis, neque quam aliquam lectus, ut tincidunt orci justo et nibh.
~hc~ end tiki_plugin ~/hc~

5.If I do the same procedure using the Wiki Sandbox it works just fine!



 

 

 

Unassigning several users from a group fail, only one is removed.

Check the instance;
Go to : http://bsfez-11581-6534.show.tikiwiki.org/tiki-admingroups.php?group=The%20group#contenttabs_admingroups-3

Try to unassign more than on user from the "The group". Only the first one is removed.

Copied some suggestion I just throwed on irc..., after fighting each time on some of my production sites to manually send messages to many users which are kind of lost some times at the beggining of their participation in a tiki-site-powered community.

{QUOTE()}
(11:37:39) xavi: I was just wondering about a new and easy improvement of the registration process of new users to a community sit eusing tiki
(11:38:07) xavi: just through allowing an admin to add acustomized welcome message to new users successfully registered to the site...
(11:38:29) xavi: ... with the text and links he might need to tell to new users....
(11:38:52) xavi: ...in a similar way to what mailman does for the welcome message to new users...
(11:39:48) xavi: ...I imagine a simple text area, like site identity does, where the admin can write any simple text (with or without wiki markup? like the newsletter feature does/allows)...
(11:40:45) xavi: ...so that the admin can set that message easily (without manualy searching for the appropiate template to hack through ftp)...
(11:42:48) xavi: ..and the the new user, can review the infos and tips that he/she needs to know on that site: "now you can: # watch that forum where that important thing is discussed.... #join that newsletter/blog/articlefeature to be up to date about news from that community, #review and/or subscribe to that tracker..., ...
(11:45:22) xavi: oh well, I can't code php+mysql myself (yet, at least ;-) ), but I guess that this shouldn't be that difficult nor time consuming to an experienced coder, provided that that person agrees on that this feature is "low hanging fruit" to improve the experience of newcomers to a community, through improving the communication while the first steps of that person in the community site...
{QUOTE}

This could also be important for ((Workspaces)), and ((Organic Groups)). So that, not just to register (join the registered group), but as a customized message per group, so that, when joining a new group (at registration time, or later on through the subscribe groups plugin), you get the specific message with hints, links and remindings of things adapted for that group.

{include page=Roles and Permissions}

When you set some expiry time for a group membership (through the admin groups interface), this information is stored in mysql table users_usergroups, and this is taken into account when you use ((doc:PluginMemberPayment)).

However, in other cases of letting a user join a group which has some expiry date set, that information (expiry date) is not stored at mysql table users_usergroups as expected.

Reproduced here:
http://xavi-9794-5946.show.tikiwiki.org/tiki-index.php?page=HomePage
u: admin
p: 12345

You can also test with a few users already created:
u: foo1
p: 12345

or
u: user1
p: user1

Cases:
!!! a) Through usual Registration
if you set some group to be selected at registration time
You can register a new user to test case (a), and select either Group1 or Group2 at registration time (both have expiry date 2 days later):
http://xavi-9794-5946.show.tikiwiki.org/tiki-register.php

!!! b) Through Plugin subscribegroup
if the user clicks at ((doc:PluginSubscribeGroup)) (with perms and site config set up appropriately),
http://xavi-9794-5946.show.tikiwiki.org/tiki-index.php?page=HomePage#Plugin_subscribegroup

!!! c) Through Plugin MemberList
if the user selects to join him/herself thorugh ((doc:PluginMemberList))
(with perms and site config set up appropriately), or the admin join a user to that group
http://xavi-9794-5946.show.tikiwiki.org/tiki-index.php?page=HomePage#PluginMemberList

However, looking at the user through tiki-assignuser.php?assign_user=foo , the right expiry information is shown.
http://xavi-9794-5946.show.tikiwiki.org/tiki-assignuser.php?assign_user=foo1

But if you use ((doc:PluginGroupExpiry)) (which looks for that date at table users_usergroups) no date is found and it reports back that the group membership never expires.
http://xavi-9794-5946.show.tikiwiki.org/tiki-index.php?page=HomePage#PluginGroupExpiry_info

In addition, it seems that someone already noticed that type of issue, and this comment can be found in lib/userslib.php > function get_extend_until_info:
{CODE()}
(...)
function get_extend_until_info($user, $group, $periods = 1)
{
//use these functions to get current expiry dates for existing members - they are calculated in some cases
//so just grabbing the "expire" field from the users_usergroups table doesn't always work
(...)
{CODE}

---
Update {sign user="xavi" datetime="2016-05-27T14:38:26+00:00"}:
* this issue seems to be fixed in Tiki 15.x (as of r58705, at least). The 3 use cases work as expected (nice!). The extra code in 15.x would need to be backported to 12.x, I guess.
* Assign user to groups has got a regression in 15.x: you cannot see (nor even edit) the group expiry date through the standard user administration UI in 15.x: when you click in "add or remove from a group" in 15.x, you are sent in a modal to this type of url:
+ __tiki-ajax_services.php?controller=user&action=manage_groups&checked=foo1&all_groups%5B0%5D=Admins&all_groups%5B1%5D=Anonymous&all_groups%5B2%5D=Group1&all_groups%5B3%5D=Group2&all_groups%5B4%5D=Registered&offset=0&sort_mode=login_asc&numrows=25&modal=1__
+
+ and no expiry information is shown.
+
+ While in Tiki12, you are sent to:
+ __tiki-assignuser.php?assign_user=foo1__
+
+ This has been added as a new bug report, since it's another issue (regression):
+ [item5953]

I created a fairly basic tiki setup using a brand new Tiki 21 instance (aimed to be used in production next week)

I applied the Collaborative_community_12x profile.

When attempting to edit the registered group to remove the homepage, or select anonymous in the inheritance field, I can't save because this errors blocks the process:

^ Template Group children cannot have permission: Editors ^

I didn't select anything with editors at that level. Nor I did attempt to do anything with templated groups yet, but I was aiming to change basic options yet.

What's going on? Is this "templated groups" feature ready for production?
How can I disable the templated groups and roles options, in order to avoid their issues with basic behavior and setup of a basic Tiki site not requiring that level of complexity?

It should be optional, shouldn't it?
---
Reproduced cleanly in a brand new site at show2.t.o (on trunk since 21.x is not available yet at show2.t.o), and it's clearer to me that this is candidate to release blocker: too serious of an issue with a basic setup and expected change by tiki site admins willing to tweak the basic groups to their needs.

Steps to reproduce:
(1) Log in as admin here:
http://xavi-9794-7325.show2.tikiwiki.org/tiki-admingroups.php?group=Registered
u: admin
p: 12345

(2) Remove the contents of the homepage field and attempt to save. Error message is triggered.

HTH

This is a wish to create a show instance on to test out the Templated Groups feature - there may well be bugs...

Well, the setup all worked as described here ((dev:Templated Groups)), nice!

Using the plugin groupList you should be able to see recursively the included group from a group.

They are not displayed when the option is set to yes.

{img fileId="1557" thumb="box"}

We have 3 Group related fields for the tracker feature.
Seems each one do a bit of the other and have some broken or to be perfected mechanism.

We should merge functionalities and have a single field that do "anything" groups.

A nice feature would be to be able to trigger a group transition inside a tracker plugin. (Not only in the memberlist plugin)

My idea is to use it ([https://dev.tiki.org/tiki-view_tracker_item.php?itemId=5948|In conjunction with this request]) to make a workflow of accepting a user based on a group tracker the user has filled to join a group. (An application form, in other words)

Thanks Tikiers

hi
I am using tikiwiki with external authentication (CAS JASIG) and i am able to authenticate users.

The problem is though the user on first login is created (if not in tikiwiki) the system does not assign the default group to that user

Is this a missing feature or i am doing something wrong?

Thank you in advance

Tiki newsletter works well for small volumes.

But for large volumes, as with any web app, sending emails from a server can be a challenge. Risk of being flagged as spammer, high server load/difficult to throttle, limits from your web hosts (ex.: max x emails per hour), etc

A helpful alternative would be something like this:
https://addons.mozilla.org/en-US/thunderbird/addon/4883

So my Thunderbird client or desktop newsletter application (ex.: [http://gammadyne.com/mmail.htm|Gammadybe Mailer]) should be able to access the TikiWiki database to generate recipient list.



---

Another approach is to make the Tiki contacts (address book) accessible via the LDAP protocol and thus, email clients can access.

Related:
http://www.egroupware.org/egroupware/index.php?menuaction=wiki.uiwiki.view&page=AddresbookAccountsConcept

This is for internal groups within a wiki, a bit like ((workspace))s.

Some pages have special perms. We'd need a way that new pages created from these inherit permissions.

It could be possible to do via category permissions but..

{syntax type="tiki" editor="plain"}
To reproduce:

#list categories as administrator
#assign some permissions to a single group for a single category
#go to the page to edit the permissions again
#select only the group that used the previous step
#expand the categories to see the permissions already set

Result: All checkboxes are empty

Expected result: Checkboxes filled in according to the permissions set

{syntax type="tiki" editor="plain"}
Confirmed on clean install of 2.4. Testing on opensourcecms.org, it does not appear this bug carried into 3.0. Have not found this reported in the forums nor bug tracker.

Since upgrading to 2.4 (sorry, only have Fantastico), there is a bug introduced with the permission level assignment capability (level configuration at bottom of tiki-assignpermission.php page). If used once as expected / described, then any further "update" to permissions in that same group will ''Null'' out the whole "Level" column in the __users_permission__ table.

Go to __groups__, __admin a group__, __admin its permissions__. Click "level configuration: show" way at the bottom. Do an assign of a level to that group and hit update. Once done, simply hit the normal "update" button in the "assign permissions" section. Does not matter if you change a permission or not. Now if you try to "level configuration: show" again, the level fields for every permission are nulled out and no levels appear in the "assign" list at the bottom of the page. Browsing the table in PHPMyAdmin confirms this behavior.

Note that you do not have to do a level assign a second time. Simply trying to change the inclusion of any individual permission (or making no changes but simply clicking the update button in assign permissions) will cause this to occur. Also, it does not matter whether "level configurations" are shown or hidden.

...

Couldn’t reproduce

I see strange behaviour when setting the "PluginRegisterMemberPayment".

On my fist save it show something close (I didn't ask to see the users... but may be because I'm admin...) to the parameters.

Then after a refresh logged as admin or logged as registered user it doesn't show the settings. Using an incognito windows and flushing the cookies doesn't helps. (on the first browser I'm admin and a simple user on the second)

{mediaplayer src="display1855"}

I categorized it as a regression, because it used to work fine and was broken.

Documentation page: https://doc.tiki.org/PluginRegisterMemberPayment

It is reproducible, see the show instance.

By the way if I load the instance page as Anonymous I see an error message "Insufficient privileges". I don't see an information in the doc about not allowing Anonymous to see the plugin, On the contrary the plugin is described as a way to Register and Pay.

On a Tiki23 I set login to use user tracker information and a corresponding tracker.
User can register and they are assigned to group "Registered".

My use case is that when registering from a specific page the user should be assigned to a specific group.
The group "Mygroup" with the option "User can assign himself or herself to the group" to y (enable)

For this I use a tracker plugin and set it like this : registration="y" chosenGroup="Mygroup" validateusers="y"

The user using this tracker plugin will be assigned to registered no matter what.

Check the instance.

---

In the html I see a hidden input to assign Registered to the variable chosenGroup
{img fileId="1681" thumb="box"}

I tried to hard coded the value (<input type="hidden" name="chosenGroup" value="Mygroup">) at register-groupchoice.tpl to test but it didn't work.

Please see ((workspace roadmap))

On creating a group, group is created but a false error warning is displayed wrongly.

Check adding a group on the instance.

On Safari the error is different:
{CODE()}AJAX: error 0 (rejected) for URL: tiki-ajax_services.php?controller=group&action=new_group&modal=1{CODE}

Started in 3.0, needs to be used in tiki-admingroups.php and propagated to various places where permissions are set.


Also on wish list: A way to put more emphasis on more important permissions.

Either basic vs advanced or an ordinal column (top put more important stuff at the top)

So for a wiki page, view, edit and history should be at the top or in basic while tiki_p_use_as_template and tiki_p_export_wiki should be in advanced

It would be useful to extract all permissions of File Galleries or Wiki pages or Forums, etc

This would provide a way for admins to know who actually has access to what.