Category: Group

Would we nice if we pushed a little bit in Group Tracker usability.

At the moment I see it as nothing different as a tracker itself. When there is a group tracker set in a group, when you join the group, nothing happens.

My suggestion is to make it to when you ask to join a group, you first are asked to fill in the group tracker, and than you join the group. To make it an obrigatory step in joining a group. (At the moment you can join the group and than fill the tracker, but that allow someone to join and not fill in the tracker) I was thinking of also make use of the Plugin Tracker Item Field, to check if the user have already filled in the tracker, so it can join the group.But that also allow a user to fill the tracker and not join the group. Anyway, I think there might be a way to bind these two things.

A little more would be to make an approval workflow to the admin see the tracker item of the applicant to the group, and inside it approve or not the user in the group. To use it as an application form.

Thanks Tikiers

Fernando

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

When you enable the tracker option to "Create a group for each item", the group created will have no name associated to it, making it impossible to be used.

When you try to edit it, the system open up to create a new group.
When you try to create a second item, no group will be created (because there is already a nameless group)
The remove funcion works.
When you try to modify its permissions, you go to global permissions.
When you open the item list in the admin panel, there will be the fieldId item that created it, in the groups name.

I guess to fix it we should have to take a look in the naming of the created group, in my opinion that is what is causing this issue. Will take a look, but can`t promise I`ll find it =P

Show instance:
admin
12345

Thanks

Fernando

When I want to manually add a user to a group (while being admin!), I go to that group's admin page, and use the dialog "add or ban users", select the user I want to add to the group, which gives me the popup dialog "Please confirm / Add the following user to group GROUPNAME *username ?", which looks perfectly alright. When I confirm this, I get the error message "Error. One or more users must be selected".

Something weird is going on...

GroupWatch on Calendar sends copy of all emails to some user with admin perms
See this setup, in a Tiki 12.x svn:
* GroupA has users: user1, user2, user3, user4
* user5, user6 exist, but are not in GroupA
* user1 & user2 belong to Registered, and GroupA
* user3 & user4 belong to Registered, GroupA, AdminsGroupA
* user1, user2 & user3 receive individual emails from notifications (no daily report set).
* user4, user5 & user6 have daily report set.
* Calendar1 has groupA set to receive notifications through the Group Watches feature.

* AdminsGroupA has a few extra permissions set, through inherited groups, related to calendars, and in many other areas.
(maybe the best way to reproduce would be to debug a copy of the production site)


How to reproduce (hopefully):
* user4 adds an event to the Calendar1
* user1 & user2 receive only one email each, with the notification of the event.
* __user3 receives 3 emails and it should receive only 1__: one from the notification email sent to his email as "To:", but also a copy of the email sent to user1, and a copy of the email sent to user2. The email from user3 is not set as cc, so it seems as if it was set as "bcc"
* user4 sees only one event in the daily digest received.
* user4 receives 3 emails with notification digests: he receives his own, plus a copy of the notification email for user5, and another one for user6. [[__this looks as another bug non-related to Calendars, but with the notification watches system__]

In the real setup of the production tiki site, there are not 3 users but many more, and therefore, the extra notification emails per event in the calendar get to annoy users...

The same setup worked properly in Tiki9, since this was reproduced in a production site recently upgraded from Tiki9svn to Tiki12svn.
---
Annoying. I can't seem to reproduce the issue in the show instance. :-(
But I promise there is some conflicting set of settings or something in our tiki site once we have upgraded it to Tiki12, since the issue is happening. :-/ {sign user="xavi" datetime="2014-11-05T12:46:21+00:00"}

If any developer is willing to debug, I can share an annonimized db dump of our tiki site. Drop me a message at xavi(a)tiki.org
---
The problem might be related to this other bug report:
https://dev.tiki.org/item5573

After upgrade from Tiki12, testing:
https://site.domain.com/ shows
^Error
No name indicated for wiki page^

I was expecting HomePage

The same upgrade from Tiki12 to Tiki15 does not have this issue.

I can access the normal HomePage through https://site.domain.com/tiki-index.php?page=HomePage

I look up in https://site.domain.com/tiki-admin.php?page=wiki and I do see
Wiki homepage: HomePage

As confirmed in CLI:
web# php console.php preferences:get wikiHomePage
Preference wikiHomePage has value HomePage

Note: option ''Group Homepages'' is active and Anonymous does not have one. In Tiki 15 and before, it would logically default to the ''wikiHomePage'' value, i.e. HomePage

There seems to be a bug in the process of creating new user groups. When you log in as Admin, and go to tiki-admingroups.php, you should be able to create a new group of users. There is a tab "Create group".

When you want to create a new group, obviously you have to give it a (new) name. So you enter that, and a description. For starters, you could have it inherit rights from Anonymous. If you don't need a registration tracker, you can leave this out (e.g. if you do not want that users can assign themselves. Example: You want to create a new group of "premium users" that will get additional rights to see some content not visible for others).

If membership shall not expire, there is no need for an expiration date.

If you do all that, you will get a confirmation dialog "Create the group GROUPNAME?". You click on Create and - get an error message

"Error
Group name cannot be empty".

But group name was NOT empty... Actually, the whole dialog "Create the group GROUPNAME?" would not make sense IF it would be able. So even if the error message "cannot be empty" would work correctly, which it doesn't, it would come too late, it should be before the confirmation dialog...

There is also a PHP error, which might (or might not) be unrelated:

"NOTICE (E_NOTICE): Undefined variable: groupcolor
At line 411 in tiki-admingroups.php"

{syntax type="tiki" editor="plain"}
Currently, users cannot join groups even when the `userChoice` option (“User can assign himself or herself to the group”) is enabled, unless they also have additional group-related permissions.

This change allows self-assignment when `userChoice` is enabled, without requiring extra permissions.

The `userChoice` option is intended to allow users to join groups themselves, not to grant permission to add other users. Requiring `group_add_member` contradicts this purpose.

The `group_add_member` permission remains enforced when adding other users.

This aligns the behavior with the expected purpose of `userChoice` groups.

I am sent here

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

{syntax type="tiki" editor="plain"}
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)

This tracker is made to help filtering and sorting the features vs categories vs options we need to tag a bug/regression/wish with.

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

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 ^

{syntax type="tiki" editor="plain"}
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)

{syntax type="tiki" editor="plain"}
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.

{syntax type="tiki" editor="plain"}
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

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.

Right now, group expiry just removes the user from the group.
In use cases of membership management in associations, or business, in which members pay a fee per year, this feature is needed for an easier setup without so much intervention of the admin in so many steps.

Scenario: NGO with 3 levels of users:
* A) "regular members", needing tyo pay fee FA
* B) "associated members" , needing tyo pay fee FB
* C) "students", needing tyo pay fee FC

2 levels of time-dependent fees for each group:
* first year you pay feee F*1
* from second year onwards you pay a different fee F*2

When the membership payment for a year is over, that user should be automatically re-assignable to another group defined in the group transitions, which should allow to set conditions for the trigger to happen:
* when group expiry happens
* when freeperiods frmo ((doc:PluginMemberPayment)) expire
* when some tracker field = some value, higher/lower than some date or other tracker field, etc. (this one is just brainstorming; it should be thought more {sign user="xavi" datetime="2016-05-27T10:51:06+00:00"})

This way, they can be requested to pay for the fee F*2, knowing that they have to pay FA2, FB2 or FC2. With current codebase, after gruop expiry, you do not know which group that user belonged to, and you can't offer that user the right fee to be payed for with plugin MemberPayment.


HTH

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