Category: Permission

After upgrading from 1.9 to 1.10 the permissions

"tiki_p_view_categorized" and "tiki_p_edit_categorized"

on the page

tiki-categpermissions.php?categId=

will not appear in the dropdown just below "Assign permissions".

Consequently, it is not possible to assign this permissions,

This problem disappears after emptying ./temp/cache/ directory.

I use TikiWiki as a platform for teaching at the college level, and one of the main things I do is require that students create and maintain their own blogs -- each student has one blog and should post only to that blog. My suggestion is that although I understand why there's an initial option to "allow others to post to this blog" in the blog create dialogue box, it would be a good idea to leave this option's availability and visibility up to the administrator -- in my situation, this option, if accidentally checked by students, creates confusion at posting time. I don't want students to see this come up as an option when they create their personal blog.

Permissions are displayed incorrectly on the
"Assign Permissions to this Object" page of
tiki-objectpermissions.php for a Calendar (other object types not tested)

If there is more than one group assigned then the boxes show the correct permissions

If there is only one group assigned no permissions show

If a 2nd or subs group is added then the boxes show the correct permissions

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

An anonymous user without edit permissions can edit create a new page.

To Repeat:
1. Be logged into a user with no edit permisssions
2. Find a red ? link to an uncreated page.
3. Click the link
4. Note you don't have permission to edit/create the page.

5. Log out
6. Click the red ? link as Anonymous
7. Note you can edit the new page
8. Save the page - Note the error:

An error occured in a database query!

Context:
File tiki-editpage.php
Url tiki-editpage.php
Query:
insert into `tiki_user_watches`(`user`,`event`,`object`,`email`,`type`,`title`,`url`) values(?,?,?,?,?,?,?)
Values:
0 NULL
1 wiki_page_changed
2 LinkToLocPageFigs
3 NULL
4 wiki page
5 LinkToLocPageFigs
6 tiki-index.php?page=LinkToLocPageFigs
Message:
Column 'user' cannot be null
Built query was probably:
insert into `tiki_user_watches`(`user`,`event`,`object`,`email`,`type`,`title`,`url`) values(NULL,'wiki_page_changed','LinkToLocPageFigs',NULL,'wiki page','LinkToLocPageFigs','tiki-index.php?page=LinkToLocPageFigs')


9. Take note that though the error happened, the page was created.

On clean installs (empty databases) of TW 1.10 and 1.9.11 (also tested and confirmed on the clean 1.9.11 install on opensourcecms.com).
After users (perms tiki_p_create_blogs and tiki_p_blog_post enabled)create a blog they can proceed to post to any other user's blog. More precisely, on the post blog page, a user can select all blogs from the "Blog" field

Contributors

So I could show quick_edit module to users with tiki_p_edit

Related:
[wish1783|Menu & modules contextual to category of currently show item (wiki page, article, tracker, etc)]

for example:
5 users in group home
6 pages in category home

I want all public can view these 6 pages in home category, but only these 5 users can edit pages content ( not the objects in the category, it is the content of the page!! ).
I know I can setup the permissions page by page to the home group, but what I am looking for is category to group relationship, not page to group, don't want to do it page by page, or maybe there is one way to do that, but I don't know yet.

Thank you very much.

Have a good day.

Best,
Peter

From irc channel, today.
Summary (full log below):

tiki-assignpermission.php in tiki 3.x seems to send the whole bunch of permissions for a group in the POST variable to the server, even if you just assign 1 new perm. And the suhosin patch for apache seems to restrict the size of the POST, so that it gets truncated at some point, before reaching the new permission/s to be assigned

that was for group "admin", which includes (inherits) many many perms from the lower level groups

workaround: filter first for a section (wiki, in my case), so that the list of perms is reduced to a smaller number. Assign the perms related to plugins, and then it works with no problem
Moreover, there seemed to be a problem with mod security (with the standard rules coming to Debian based servers), which was causing error 403 with that tiki-assignpermission.php .... once the sys admin disabled modsecurity for our site, tiki-assignpermissions.php worked as expected with the workaround described above


{CODE(wrap=>1)}
wtf*, there is something weird with tiki-assignpermission.php in tiki 3.3...
... I try to grant the 3 perms related to plugins to the group "Admins" (they have tiki_p_admin also already), and I get: You don't have permission to access /tiki-assignpermission.php on this server. (with a scary apache white page)
I mean a 403 Forbidden page from apache
to me that there is something wrong in the LTS for assigning permissions... [11:31]
xavi aha, after conversation with sys admin in that server, I got the source of the problem, and workaround :-)
tiki-assignpermission.php in tiki 3.x seems to send the whole bunch of permissions for a group in the POST variable to the server, even if you just assign 1 new perm. And the suhosin patch for apache seems to restrict the size of the POST, so that it gets truncated at some point, before reaching the new permission/s to be assigned [12:02]
xavi that was for group "admin", which includes (inherits) many many perms from the lower level groups
ok, workaround: filter first for a section (wiki, in my case), so that the list of perms is reduced to a smaller number. Assign the perms related to plugins, and then it works with no problem
Moreover, there seemed to be a problem with mod security (with the standard rules coming to Debian based servers), which was causing error 403 with that tiki-assignpermission.php .... once the sys admin disabled modsecurity for our site, tiki-assignpermissions.php worked as expected with the workaround described above [12:02]
marclaporte will you report the bug to suhosin? [12:09]
xavi hi marclaporte, it might very well be not a bug, but a conflict between the size of the post that tiki sends, and the size of the variable allowed by default values by suhosin in apache, which (as far as I've been told) it's customizable.... [12:12]
marclaporte ok [12:12]
xavi so the chances that they will not consider it a bug are high (maybe similar for tiki, which wouldn't be considered a bug, but some "bad luck" of using such a long default list of perms) [12:13]
marclaporte so nobody's "fault" but it's doesn't work [12:15]
xavi btw, thanks for message introducing to the author of jquery spreadsheet...
"it doesn't work": well, it does, if you filter the long list of perms for a section first
or if you moun your sys admin to find out how to increase that default size in suhosin [12:15]
{CODE}

Contributors

Contributors

I have a group which does not have permissions to admin content templates in their category or the global permissions (the only permissions applying to the group) yet the group is still able to admin content templates.

Object permissions do not actually apply to individual files in a filegal. Despite this, we have UI to change said permissions. Trying to apply perms on a file affects the perms on the parent filegal. Very confusing and frustrating usability bug.

Hello, former library employee now library volunteer who is helping a library update its tikiwiki 3.x intranet to 7.2 and encountered a strange bug that I am stuck on.

Upgrade seemed to go smooth, with a fresh directory install and pointed to the SQLi backend of the 3.x install in a test environment.

When I went to login with the known local admin account within tikiwiki, it allowed me to login but i could not access any of the admin modules without getting a lack of permissions error. Somehow the admin account is not associated with the admin group, although works fine in the 3.x live install.

Issue is compounded then that I cannot add admin to the admin group, because I cannot get access to the admin modules to do this!

I tried to do my own research on this, and actually did see some IRC logs where someone else had a very similiar issue although I did not see a resolution.

Any ideas how to fix this? Can someone give me some guidance into the tikiwiki sql structure whereby I might be able to change this within the table itself?

It will be very useful when TikiWiki is used as a combined portal & Intranet


The key (and link to permissions) is already on tiki-listpages.php (great!)

Now, a green key could indicate this page has special permissions.

And maybe even a third key (say blue) indicates that the item is inheriting permissions via the category.

You cant set it that individual polls can be set to viewed by only certain groups.

when a wiki-page is added to a category, it's is no longer viewed to anonymous users. (Login screen appears) By removing the page from the category it appears again.

Assign Permissions with Level Configuration,
thus drop-downs in the table
tiki-assignpermission.php?group=Admins&advanced_features=y
ordering by level does not order correctly.

Guys, I have to set up a company wiki, which is completely structured from top to bottom. So I noticed a very annoying thing about tiki.

Currently if you want to create a page, that is destined to be part of a structure, you have to create it using the navigation bar and set the option "as child".

But what if a user creates a new page from within a structred wiki page? I.E. If he simply sets up a new link to an non existing site. The new page is created as an orphan which is definitely a "no go" for a completely structured wiki. Pages like this have to be manually assigned to a structure by the admin.

So I request an option, that __forces pages created from within a page in a structure to be automatically part of the same structure__.

I guess even in pages like doc.tw.org this would be very helpful.

After a clean install of r15460 w/ a new database, using the default enabled profile, i enabled structures via the wiki admin area.

Even though I was admin, I coulden't create / edit structures until I gave myself permission in the privileges settings.

The admin user should probably have most permissions by default, unless there is a particular reason to exclude a permission.

After a clean install of r15460 w/ a new database, using the default enabled profile, i enabled structures via the wiki admin area.

Even though I was admin, I coulden't create / edit structures until I gave myself permission in the privileges settings.

The admin user should probably have most permissions by default, unless there is a particular reason to exclude a permission.

Hello,

Relating to id2936 id2950 and another id lost (mine but when the author was not set always into track id data's.

It remains impossible to an admin to changed quite anything depending of admin (can create wiki, articles) but not to end any admin task.

The action as, change a user prefs etc, disconnect admin and send the ERROR Connect page __access not allowed__ so the corresponding sites are dead sites.

An installation of 3.3 or upgrade to 3.6 must be done again from database backup.

The problem is that if users has been connected between the upgrade and the necessity for admin to make some changes (I have made...) I had to manually add articles and wiki pages from sql.

We must admit that upgrade from 3.x to 3.x is impossible in some cases unknown, not yet found

I test today if an upgrade 4.2->4.3 had an effect but none.

trebly