Category: Group

Sometimes, we want people to participate to one wiki page, to access their user tracker to update personal information or access a ((workspace))

Right now, we need to

#create a user
#create a group
#assign user to the group
#give permissions to group ( in general or for a specific item)
#inform this person, typically by email, on how to access this page


Instead, I would want to
#add an email
#pick the permissions this person has
#any limitations (works x times, or for x days/weeks)
#an optional message

And the system should send a 1-click login email (an email with a link in it which is unique / very difficult to guess).

Whoever clicks that link
*Would be authenticated with the appropriate permissions and according to the limitations.


Related:
Expiry date for group membership
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1071

Somewhat related:
Send welcome email (by admin to new user or user that has not connected in a while)
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1016

Contributors

Contributors

Contributors

Contributors

Contributors

If you require login but assign just a custom module to pagetop without selecting at least the registered group, it will kill your Tiki.

You'll have to edit the MySQL tiki_modules table and delete your module to make it work again.

We are running Tiki 6.2 (clean install), on a Windows 2003 Server, Apache 2.2.16 w SSL, PHP 5.3.3, remote MySQL 5 database.

What we would like to do in our organization is for an admin to create group MyGroup and assign Bill to the group. The admin would then give the MyGroup object permissions:
* Can add group members (tiki_p_group_add_member)
* Can remove group members (tiki_p_group_remove_member)
* Can invite user to my groups (tiki_p_invite_to_my_groups)

At this point I would figure that there would be some kind of interface so that Bill could have a user selector and bring people into his group. I have checked around but I can not see any mechanism to do this.

We want to avoid our admin to manage groups for 1000's of users.

On a side note, we also investigated letting users select their own groups however we can also not find a mechanism to do this. We enabled all permissions we could think of such as:
* Can subscribe to groups (tiki_p_subscribe_groups)
* Can join or leave the group (tiki_p_group_join)
* In the group we selected "User can assign to the group himself"
but we can still not find where the user can change his group.

Our users sign in with their LDAP (AD) logins and therefore do not go through the Registration process.

Any help would be very much appreciated as this is a big issue for us right now.

Ex.:
tiki-adminusers.php?group=Editors


It will make it easier to manage groups.

If I create a new group in tiki-admingroups.php, and want to add a user, I must go to tiki-adminusers.php

I should be able to add users to groups from tiki-admingroups.php, with a drop-down (if < 500 users) or a search username box (if users > 500) , or something like this...

When you try to edit and rename the group in Administration->Groups appears the following error message:

An error occured in a database query!

Context:
File tiki-admingroups.php
Url tiki-admingroups.php
Query:
insert into `tiki_group_inclusion`(`groupName`,`includeGroup`) values(?,?)
Values:
0 G_Communication
1 Registered
Message:

Built query was probably:
insert into `tiki_group_inclusion`(`groupName`,`includeGroup`) values('G_Communication','Registered')

_____________________________________________________________________

Step to reproduce:

Create a Group G.
{
Assign to this group some user
Assign to this group a default
}
Rename the Group G into G'
_____________________________________________________________________

Notes:

I checked the security flag because where there's a DB error could be there a SQL security issue.

After some bad experience (ours and from other users), Rick (Rick99) and I suggest:

^RFE should be that the following username should __not__ be changable or deletable:
* __admin__

And the following groupnames should __not__ be changable or deletable:
*__registered__
*__anonymous__

Additionally, there should be a usergroup __administrator__ that has ''all'' permissions. This would allow Tiki-admins to easily create new Admin logins, with their own usernames.
^

__added: ensure password reminder works out of the box__

A couple of usability issues could be fixed here.

a) remind/reset passwords is off by default - should be on?
b) no email is set on admin by the installer

this would prevent most newbie lost admin password issues i think. - mlpvolt


Last [http://tikiwiki.org/tiki-view_forum_thread.php?comments_parentId=24817&topics_threshold=0&topics_offset=0&topics_sort_mode=lastPost_desc&topics_find=&forumId=2|thread about it at tw.o here]


Related issue: http://dev.tikiwiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=1074

The group members tab is falsely capped, only displays 24 members, more exist in group when you check the admin>users screen.

It would be lovely to set some new user defaults at
* Admin (home) > Login > User defaults, and/or
* Admin > Groups > (Edit a single group)

The ability to Subscribe/watch/monitor new users in the site or to that specific group, to specific Tiki objects.

Which tiki objects?: I would say, in this order:
# specific forums
# specific blogs
# specific calendars
# specific newsletters (ML: we can already subscribe groups to newsletters)
# specific wiki pages
# specific structures
# specific trackers
# specific categories
# new articles

This is specially useful for new users of the site, where they don't know yet how to subscribe to specific areas, etc. Very needed for educational scenarios, but I can see many other places where new users are a bit lost for some time while they learn how to use the Tiki site.

Related:
*[wish988|Forum: Let forum admins/moderators add groups and/or users as watching the forum]
*[tiki-index.php?page=Business%20Plans|Let small business start ups access collaborative sharing where the document being shared is not visible by anyone else]


Anywhere there is a watch eye, it should be possible for an admin to have group members watch this category

When I was testing various CMS/Wikis for a project, I ran across a module for another (Joomla or Drupal, can't remember which) CMS which allowed a user role or group to automatically generate a personal page, an image gallery, a weblog and any type of content page. It would be extremely useful for my project, but one of the few things missing from Tikiwiki (which is why I am implementing Tikiwiki, it has all of the other features I need in one install).

When I assign a theme to a group and submit the change, when the admin-group page displays again, the theme selector shows "site default" instead of the theme name I chose, and the theme being used for the group doesn't change.

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.

You create a blog, Assing local perms to a group which name contains an space (or special characters such as é, è, ñ, ç, ...). Then when you attempt to delete the local permission, you don't succed. The url is something like:

http://domain/tiki-objectpermissions.php?referer=http%3A%2F%2Fdomain%2Ftiki-edit_blog.php%3FblogId%3D5&action=remove&objectName=BlogNAME

And it produces the error message saying somerthing lie "there is not enough information to show this page".

Sometimes, wehn sending a braodcast message to a given group, the message body is empty.

It is empty for the recipients, but also in the sent box of the sender.

No error message is issued, en the message is delivered with the correct sender, the correct subject, but a totally empty body.

Categories are not assigned like they are asked to in the group settings.

"Default category assigned to uncategorized objects edited by a user with this default group:"

Group chosen is not auto assigned.


Categories are also not assigned like they are asked to in the Staging and Approval settings. I will be told I am creating a staging document, it will add the prefix, etc. However, it will not move it to the chosen staging category.

I have tried this with fresh installs of 4.1 and no profile loaded during initial setup.

My application use category on groups and objects
I tried category transition in tiki4, to be honest without reading anything, the result is catastrophic: I cannot admin all my tiki because i have lost my rights as administrator.
In my SQL database all records in users_grouppermissions table have been deleted
How can I retrieve my rights?
Can I manually write admin rights in my database?
thanks

Feature suggestion: add a permission to "change group viewpoint"

This would allow a member of many groups to see a drop-down of his groups.
Choosing another group would allow only to see what members of this group can see.

So admins would be able to check that their users's groups permissions have been set up properly.

In tiki-admin.php?page=login, the "Use tracker to collect more group information" check box is always checked, so everytime you change something, the feature is enabled. Kind of annoying to have to pay attention to that all the time.

Contributors

db error in group inclusion (tiki 3.3)
Installed barebones profile on tiki 3.3, then applied Collaborative Community on top, which created the group SubAdmins.
Then I attempted to rename group SubAdmins (which includes Editors) to Editors_Web, and I got this error:

{CODE(wrap=>1)}
Context:
File tiki-admingroups.php
Url tiki-admingroups.php
Query:
insert into `tiki_group_inclusion`(`groupName`,`includeGroup`) values(?,?)
Values:
0 Editors_Web
1 Editors
Message:
Built query was probably:
insert into `tiki_group_inclusion`(`groupName`,`includeGroup`) values('Editors_Web','Editors')
{CODE}

This would be great ((tw:Dogfood)) to better organize our community and let users join groups according to their interests.

When I try to create new group I receive this error from MySQL:

Error


An error occured in a database query!

Context:
File tiki-admingroups.php
Url tiki-admingroups.php
Query:
insert into `users_groups` (`groupName`, `groupDesc`, `groupHome`,`groupDefCat`,`groupTheme`,`usersTrackerId`,`groupTrackerId`, `registrationUsersFieldIds`, `userChoice`, `usersFieldId`, `groupFieldId`) values(?,?,?,?,?,?,?,?,?,?,?)
Values:
0 ffff
1
2
3 0
4
5 0
6 0
7
8
9
10
Message:
Incorrect integer value: '' for column 'usersFieldId' at row 1
Built query was probably:
insert into `users_groups` (`groupName`, `groupDesc`, `groupHome`,`groupDefCat`,`groupTheme`,`usersTrackerId`,`groupTrackerId`, `registrationUsersFieldIds`, `userChoice`, `usersFieldId`, `groupFieldId`) values('ffff','','','0','','0','0','','','','')

Related to ((PayPalSubscription)), it would be useful to have a user no longer have group privileges after a certain date.


Ex.: I add a user to a group X for 1 year.

Currently (2.x), admins can configure new registrations to select specific groups during registration. I would like to request the following enhancments:

# Specify a default group. Currently, there is no default. I want to be able to configure a default group (i.e., adding checked="checked"...)
#Allow admins to confirm group requests. For example, I want to allow users to ''request'' to join an admin-level group upon registration, but I want the current admin to be able to verify this, before the user gets admin access.

This permits mailing-list-like functionality.

After, adding or removing a user from a group dictates which forums they can read and get notifications for.

Maybe we should use the newsletter functionality as it already handles group inclusions and individual opt-outs...

Like newsletters, it should be possible for people to remove themselves from a mailing. Better than 1.9.7 newsletters, it should also be possible for the admin to see who removed themselves.

{CODE(caption="tiki-login.php line ~308")}if ($prefs['limitedGoGroupHome'] == 'n' || $url == $prefs['site_tikiIndex'] || $url_path == $prefs['site_tikiIndex'] || basename($url_path) == $prefs['site_tikiIndex'] || ($anonymous_homepage != '' && ($url == $anonymous_homepage || $url_path == $anonymous_homepage || basename($url_path) == $anonymous_homepage)) || ($tikiIndex_full != '' && basename($url_path) == $tikiIndex_full)) {{CODE}

for $prefs['limitedGoGroupHome'] == 'y'
the sefurl will not match

The inheritance of permissions between groups seems to be completely broken in trunk (r33152).

For example, when Registered includes the permissions of Anonymous, granting tiki_p_admin_wiki to Anonymous should allow Registered to admin wiki pages, but that doesn't work. The same thing happens with tiki_p_view and tiki_p_read_comments.

This was discussed in thread http://thread.gmane.org/gmane.comp.cms.tiki.devel/20101

This is a regression from r32118.

Group plugin is very cool to put conditional content on a wiki page.

However, it is only an if. There is no if/else.


Say I want to show a content X to people in a group and content Y to everyone else.

Maybe we could have a new parameter?: notgroups

{CODE()}
{GROUP(groups=>Anonymous)}text for anon{GROUP}
{CODE}

{CODE()}
{GROUP(groups=>notgroups=>Anonymous)}text for the others{GROUP}
{CODE}

The group theme functionality no longer works in 5.x and 6.0.

To test:
*Set "each group can have its own theme" in Admin>Look&Feel>theme
*Admin>Groups, edit a group and try to set the default theme for a group.
*nothing happens.

*theme control - still working.
*user preferences - theme - still working.

Project to perform many of the functions of CRM using as many existing Tiki features as possible (dev notes).

I am sent here

tiki-adminusers.php?user=abc&action=removegroup&group=xyz

Contributors

Hi,

!!!This problems concerns quite all table and forms (in tables or not) with fixedwidth themes.
This is the reason while it appear in so many functions.

!!!As for most of tables in many functions, with "twist" (no other style tested) the tables of the middle (C2) either overlap C3 or are behind C3 and sometimes C2. They just have a little part outside the 990px large (in twist as the width is written into css it can't be changed by prefs).

__~~#F00:The corresponding functions are then completely unusable.
~~__

Here I write this for the example elementary function "add an element to a structure" givin in screenshots joined documents

Three scrennshots proposed are :
#What a user see
#The limit of the div as shown by firebug
#The whole div zone hidden

Sometimes, you want to show a module just for Registered, but not Admins. So a notgroups param would be nice.

This idea is from Bernard Sfez on the Dev mailing list.

As an admin, I change the group of a user, and the default group.
The user needs to logout/login or the default group is not changed

I was unable to get group sync for ldap working, and after changing two lines of code in userslib.php I was able to get it working.

The changes I made are the __procedure__ section, and I have included my settings also in case someone is having a similar issue, or is just trying to set up LDAP group sync and would like to see a working example, and in case it is useful in your troubleshooting.

Hi,

as written to the dev list, I had the problem to restrict access to some newsletters but not to all. I found a solution, but I am not sure, if this breaks nothing else. Here is the problem:

I want to set up some newsletters: One with access from anybody (anonymous users can subscribe and view the archive) and some others with access only for special groups of users.

On global permission page I set 'tiki_p_list_newsletters' and 'tiki_p_subscribe_email' for anonymous users (this permissions are not available on the object permission page).

On the object permission page for the single newsletter (accessible through /tiki-admin_newsletters.php and the key icon of every newsletter) I activate 'tiki_p_subscribe_newsletters' and 'tiki_p_view_newsletter' for the group of users with permissions on this newsletter.

With this settings I would expect, that an anonymous user browsing page tiki-newsletters.php would see the list of newsletters, in this case showing only the public newsletter. But in this case there is an error (You are not logged in). As a privileged user (allowed to see all newsletters) the page is accessible but empty, not showing any newsletter.

How to reproduce:
1. Allow Group Homepage
2. Set homepage for anonymous group: agr_home
3. Set homepage for registered group: rgr_home
4. make default page agr_home page
5. login -> you ll be redirected to rgr_gome -> thats ok
6. logout -> you ll be redirected to http://yoursitename.com/agr_home (note: not index.php?page=agr_home)

Features Classification

Contributors

Contributors

I initially reported the bug as if it happened only when you had more than 10 groups, and wanted to assign the users to a group greateer than the 10th postition. Now I've realized that it also fails for any group in the list (also for one of the groups within the first 10 listed): the selection of users is lost, thus no user is assigned to the group you select.
:-/

----
To reproduce the bug:
You need to have more than 10 groups defined in the Tiki.
And also several users (+100 in my case)

From admin users menu:
* Select several users (in my case, I selected to view 20, ordered by last login)
* click on manage groups assignments

^
__GROUP PART__
If the group you want to assign them to is not in the list of the first ten (for instance, it's the eleventh in the list alphabetically ordered), then you cannot select that group for those users.
If you try to go to next page of groups (I guess), then the selection of users is lost.
Using 1.9.2.
-----
This bit was fixed by sylvie last week. Xavi (31/01/06)
^
Still buggy:
^
__USERS PART__
To reproduce:
Reorder the list of users by any field so that you get some users in the list that where not seen at the default view of users (that's a __key point __to reproduce the bug).

Select some of those users, to assign them to a group. After I click on submit button (with "manage group assignments" selected), then the page is loaded with the default ordering, so that those users are not listed in the page. If I select then the group to have them assigned to, and submit, the users are not assigned to that group.

However, if I restart the process, but request to show 1000 users (what ever number, but ensure you list ALL of them). Reorder again users (last connected, for instance). Then select some of them. Click to "manage group assignments), and then, the page will loose the ordering, but at least you'll be able to see your users among the long list, and tehy keep the box toggled on (so that __selection is not lost!__). In this case, assigning to a group worked!

The bug must be somehow related to the registers that are ot selected to be shown, even if they are still selected to be assigned to the group.
Hope this helps to fix the bug. Xavi 31/01/06
---
This second part was fixed by sylvie after the report, later on the same 31/01/06...,
at tiki-adminusers.tpl ^

I assigned a user module "My Module" to the group "Anonymous"

'display modules to all groups always' = off

anyway my Module is presented to any group.

Any Ideas?

Using 1.10cvs from the last week of October'07.
Multiple assignment of users to a group is not working. Log shows as if those users were effectively assigned to group Editors (in my case), but after that, when I refresh the list of users, those users are still only belonging to registered group, and not Editors.

However, if I assign one by one, through the key icon, they are well set to the Editors group.

http://moviments.net/intercanvisarxius/

(this is the same site as http://intercanvis.net but for testing, using latest 1.10 cvs code)

In Tiki newsletters, it is possible to subscribe a group (excellent)
It is also possible for individuals to unsubscribe from a newsletter without leaving the group (excellent)

However, newsletter admins do not have access to this list. They should know who left the list and should be able to administer this "exception" list.

Hi,

I have set the following permissions for Anonymous

tiki_p_view
tiki_p_view_categories
tiki_p_view_categorized
etc

and the following category permissions

Anonymous tiki_p_view_categories
Registered tiki_p_admin_categories

Assign permissions automatically: Yes

Despite this neither Anonymous or Registered can view pages that have been categorized, the categories appear empty. Only way I can change this is by changing permissions on each individual page.
I've tried and tested this on 3 different installs, same problem each time. I am quite new to this but have spent many hours on this issue and would appreciate any advice.
I'm sure that there's a way but how?
Cheers

Wiki in question can be viewed at www.paddypaedia.com

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.

Preface: This is my first bug entered and I am also *very* new to TikiWiki.

With that disclaimer out of the way:

The problem is that the RSS calendar link at the bottom of the default install seems that it bypasses or overrides the security.

I had set up a restricted category and a restricted calendar tied to that category. I created a user with access and it worked fine. I logged in as a test user to make sure it was working correctly. I could see the public calendar and the public topics but not the restricted ones. I thought this is great.

Then, when I was not even logged in as any user, I clicked on the RSS feed at the bottom of the screen and guess what? It showed me all the contents of the restricted calendar and the public calendar, too.

Thanks.

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..

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

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.

Please see ((workspace roadmap))

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

Contributors