Name | Type |
---|---|
_categorized-Permissions cannot be assigned when upgrading from 1.9 to 1.10 - cache problem | tracker item |
"Allow others to post to this blog" should be possible to omit as an option when creating blogs
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. |
tracker item |
(calendar) permission display wonky
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 |
tracker item |
1-click access to be able to do certain actions (view a page, edit a page, edit user tracker, etc)
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 |
tracker item |
Caldrac
Contributors |
tracker item |
Anonymous users can create page without permissions after broken sql page shown
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`,`ur 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`,`ur 9. Take note that though the error happened, the page was created. |
tracker item |
Users able to post to all blogs - confirming and extending previously reported bug by others
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 |
tracker item |
jonnybradley
Contributors |
tracker item |
Modules use should be restrictable with standard permissions
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)] |
tracker item |
group category permissions
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 |
tracker item |
3.x: tiki-assignpermission.php fails when not filtered & default suhosin patch for apache in server
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} |
tracker item |
thess
Contributors |
tracker item |
Cyril
Contributors |
tracker item |
Can admin content templates without appropriate permissions
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. |
tracker item |
Filegal File Object permissions - does not exist.
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. |
tracker item |
When upgrading old version of TikiWiki to 7.2, admin login no longer has admin permissions
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? |
tracker item |
Add green & yellow permission keys on tiki-listpages.php
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. |
tracker item |
Add group permissions for individual polls
You cant set it that individual polls can be set to viewed by only certain groups. |
tracker item |
Adding a page to a category breaks permissions
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. |
tracker item |
Admin – Assign Permissions – ordering table by level does not order correctly (level conf. active)
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. |
tracker item |
Admin option to force newly created pages to be part of the structure they were created from
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. |
tracker item |
admin user doesn't have permission to edit structures by default
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. |
tracker item |
admin user doesn't have permission to edit structures by default
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. |
tracker item |
admin user loses admin rights after creating a user | tracker item |
All upgrade from 3.x to 4.x denies all permissions to admin
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 |
tracker item |
"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.