From: Rodrigo S. P. <rod...@gm...> - 2010-06-04 20:49:18
|
Hi, As far as I can test permission check is now working for global, category and object permissions applied to a file gallery and also category permissions applied to a single file. But would be great if someone else could test and give some feedback. The last case, category permissions applied to a single file, is working in this specific part of file galleries (tiki-list_file_gallery.php). There are still problems in other parts of file galleries (for example tiki-download_file.php) as the code does not check for permissions applied to a single file, it uses file gallery permissions instead. If someone is willing to use category permissions to individual files this needs to be fixed. Sylvie, I think the problem was wrong $res['id'] value passed in some cases to $this->get_perm_object() and not the function itself. Xavi and others, I think that is consistent if category permissions applied to a single file override object permissions applied to a file gallery. Otherwise there is no point in assigning categories to a file. But I agree with Jonny that it is inconsistent that it is not possible to use object permissions with files, just category permissions. Rodrigo On Tue, Jun 1, 2010 at 9:25 AM, Sylvie Greverend <sgr...@gm...>wrote: > I am not sure that it will work > The problem is that > $res['perms'] = $this->get_perm_object($res['id'], 'file', array(), > false); > Is bugged - as it takes the global fgal perms as the default ones and > not the local fgal perms > My 2 cents - need more time to test > > On Tue, 2010-06-01 at 13:29 +0100, Jonny Bradley wrote: > > On 1 Jun 2010, at 12:35, luci aka luciash d' being wrote: > > > > > +1 for what Xavi understands. i also believe object permissions should > override category perms... > > > > > > i suggest this structure of perms (highest priority for perms is the > last one): > > > > > > global perms > > > category perms if the file gallery is assigned OR individual perms of > the file gallery > > > category perms of the individual files if assigned > > > individual file object permissions > > > > I think this is the problem - because individual files don't have their > own perms (yet, right?), should gallery object perms override individual > file category perms? > > > > If the don't then there's not much point assigning perm categories to > files and no other way of getting finer grain permissions on individual > files, but if they do then it's not consistent with the rest of Tiki (so > what new? ;) > > > > Best would be to add object perms for files (but i don't have time - > these permission things make my head hurt!) > > > > jb > > > > > > > > On 05/31/2010 08:35 PM, Xavier de Pedro wrote: > > >> Hi Rodrigo: > > >> > > >> Thanks for bringing this issue back and proposing solutions to it :-) > > >> > > >> To my understanding, this behavior is dangerous (potentially confusing > users), because object permissions override category permissions in Tiki. > And for a file in a file gallery, it seems intuitive (At least for me, of > course, maybe not for others) that object permissions in a file gallery > should overrule any category permissions. > > >> But of course, others might consider your fix the "right" way to go... > > >> Any better idea? > > >> > > >> My 2 cents. > > >> > > >> Xavi > > >> > > >> > > >> Al 31/05/10 17:04, En/na Rodrigo Sampaio Primo ha escrit: > > >>> Hi, > > >>> > > >>> I just commited (r27402) another attempt to fix the issue regarding > file and file galleries permissions. > > >>> > > >>> I did the following: > > >>> > > >>> Check if the file is categorized. If so, get all the categories > permissions for this files and use them. If the file is not categorized, use > the parent file gallery permissions for the file. > > >>> > > >>> Note that a file will not be displayed if it is categorized, but all > its categories has no file gallery related permission. > > >>> > > >>> What do you think? > > >>> > > >>> I hope this is a improvement of the actual situation (mainly because > now category permissions for file galleries is working) but it is not the > best solution. I'm not totally comfortable with categorizing files because > it appears to me to be a inconsistent feature. It is not possible to > categorize a file through the categories interface (only through the file > upload form) and as there are no file specific permissions we apply file > galleries permissions. Most of file galleries permissions do not make sense > for a single file. > > >>> > > >>> Also, although category permissions for individual files is working > in the file gallery list. It is not working in tiki-dowloadn_file.php (with > just tiki_p_view_file_gallery is possible to download a file with individual > category permissions if you have tiki_p_download_file for the parent > gallery). I haven't check in other parts of file galleries. > > >>> > > >>> I have another client that is going to use object permission for file > galleries, so I have some time to work on this in the next days if new > issues arise. > > >>> > > >>> Cheers, Rodrigo. > > >>> > > >>> > > >>> On Tue, Apr 6, 2010 at 10:13 PM, Rodrigo Sampaio Primo < > rod...@gm...> wrote: > > >>> > > >>> > > >>> On Thu, Mar 25, 2010 at 6:53 PM, Sylvie Greverend < > sgr...@gm...> wrote: > > >>> On Thu, 2010-03-25 at 18:34 -0300, Rodrigo Sampaio Primo wrote: > > >>> > Hi Sylvie, sorry but I'm not able to find how to associate a single > > >>> > file with a category. If I try to add new objects to a category on > > >>> > tiki-admin_categories.php I can see only file galleries as an > option. > > >>> > Can you tell me? > > >>> in upload file tiki-upload_file.php, you should see the categorizatin > > >>> bos - otherwise something is wrong with your perms > > >>> > > >>> I was looking only on tiki-admin_categories.php and not on > tiki-upload_file.php. Apparently it is not possible to assign a file to a > category in the category administration page, only in the file page. > > >>> > > >>> > > > >>> > > > >>> > Unfortunately I'm not going to have time to look at this issue with > > >>> > categories. I'm working now to finish a project that uses only file > > >>> > galleries and wiki (and not categories) and all the time I can > spend > > >>> > with Tiki is to fix issues related to this project. But if any make > > >>> > any progress I can help testing as the database of this site uses a > > >>> > complex set of permissions for file galleries. > > >>> we will probably have to rollback your commit,,, > > >>> For me also, my time is limited... > > >>> > > >>> Sorry to insist here, but if I got everything before my commit both > category permission and individual permission were broken for file > galleries. Only global permissions were working. And now both global and > individual permission are working, only category permissions are still not > working. If this is the case I think it is better to keep the change until > we fix category permissions for file galleries. But if category permissions > were working and my commit broke it I will rollback. > > >>> > > >>> > > > >>> > > > >>> > If I understood correctly, even before my commit categories > > >>> > permissions was not working for files. But if this is not the case > and > > >>> > my commit broke this let me know and I will revert it. > > >>> Yes it is correct - but why usually people does not have the problem > - > > >>> it is because the global perms are tiki_p_upload_files=y and the fgal > or > > >>> the categ limit the perms. I suppose in your case you do not have > > >>> global tiki_p_upload_files=y? > > >>> > > >>> Yes, in my case no group has global tiki_p_upload_files. We are using > only permissions assigned direct to individual file galleries. > > >>> > > >>> Rodrigo > > >>> > > >>> > > > >>> > > > >>> > Thanks, Rodrigo > > >>> > > > >>> > On Wed, Mar 24, 2010 at 7:34 AM, Sylvie Greverend > > >>> > <sgr...@gm...> wrote: > > >>> > You probably as I told on IRC are in this situation. > > >>> > Following the last message I had some time ago with lph on > the > > >>> > subject > > >>> > > > >>> > The scenario in fgal is > > >>> > 1/ check the perms on the gallery > > >>> > 2/ then check for each file is no forbidden category on the > > >>> > files > > >>> > > > >>> > But Perms::get that is applied to each file by default > takes > > >>> > the global > > >>> > perms and not the perms of the fgla. > > >>> > > > >>> > The fix lph suggested is: > > >>> > $globalperms = Perms::get(); > > >>> > $fgalperms = Perms::get(...); > > >>> > $fileperms = Perms::get(...); > > >>> > > > >>> > $localdeny = $globalperms->view_file && > !fileperms->view_file; > > >>> > if ($fgalperms->view_file && !localdeny) { > > >>> > ... > > >>> > } > > >>> > > > >>> > If you have time to fix properly the bug, thanks, otherwise > I > > >>> > put this > > >>> > problem back on top of my list > > >>> > Thx > > >>> > sylvie > > >>> > > > >>> > > > >>> > On Wed, 2010-03-24 at 02:27 -0300, Rodrigo Sampaio Primo > > >>> > wrote: > > >>> > > > >>> > > > >>> > > Hi, I just commited to branch 5.x revision 26283 that fix > > >>> > the problem > > >>> > > in file galleries that I discovered and was confirmed by > > >>> > Michael. > > >>> > > > > >>> > > > > >>> > > I would like to have a feedback from someone familiar > with > > >>> > the file > > >>> > > gallery and permission system just to be sure that I'm > not > > >>> > creating > > >>> > > other bugs trying to fix this one :-) > > >>> > > > > >>> > > > > >>> > > Basically, the problem was that the function get_files() > in > > >>> > tikilib > > >>> > > was trying to check for object permission in each file > and > > >>> > there is no > > >>> > > object permission per file (only per file gallery). So, I > > >>> > changed the > > >>> > > code to check for permission in the gallery which the > file > > >>> > belongs. > > >>> > > > > >>> > > > > >>> > > There is also another problem when uploading files in > Tiki > > >>> > 4.2 when > > >>> > > the user does not have global permission to upload a file > > >>> > (maybe the > > >>> > > same discovered by Michael). In this scenario the file > > >>> > gallery select > > >>> > > box in tiki-upload_file.php has the correct gallery name > but > > >>> > the wrong > > >>> > > ID. > > >>> > > > > >>> > > > > >>> > > I have fixed this bug but it happens only in 4.x. In 5.x > the > > >>> > file > > >>> > > gallery select box in tiki-upload_file.php has been > removed > > >>> > when > > >>> > > galleryId is set, so this problem does not happen in this > > >>> > version. It > > >>> > > is a good idea to commit the fix to 4.x branch or there > will > > >>> > be no > > >>> > > more bug fixes releases of if? > > >>> > > > > >>> > > > > >>> > > Rodrigo > > >>> > > > > >>> > > On Tue, Mar 23, 2010 at 3:44 AM, Michael Pilling > > >>> > <mlp...@gm...> > > >>> > > wrote: > > >>> > > Rodrigo > > >>> > > > > >>> > > > > >>> > > I repeated your test with the same results. > > >>> > > > > >>> > > Additionally the "author" user was able to upload > a > > >>> > file but > > >>> > > then not > > >>> > > see it after. > > >>> > > > > >>> > > The problem goes away when > > >>> > tiki_p_view_file_gallery is > > >>> > > added to the > > >>> > > authors group (global perms). > > >>> > > > > >>> > > I don't think that is the intended function. The > > >>> > object perms > > >>> > > should > > >>> > > override the global. > > >>> > > > > >>> > > > > >>> > > MLP > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > On Sat, Mar 20, 2010 at 11:32 AM, Rodrigo Sampaio > > >>> > Primo > > >>> > > <rod...@gm...> wrote: > > >>> > > > Hi, I'm setting up a Tiki which is basically a > set > > >>> > of file > > >>> > > galleries with > > >>> > > > permission control for each gallery. We have > > >>> > approximately > > >>> > > twenty galleries > > >>> > > > and each gallery has three user groups (reader, > > >>> > author and > > >>> > > editor). I'm > > >>> > > > having multiple problems with the permissions > > >>> > control. > > >>> > > > > > >>> > > > To test, in a fresh 4.2 install I created a > group > > >>> > named > > >>> > > "authors" with no > > >>> > > > global permission and a user named "author" who > > >>> > belongs to > > >>> > > this group. Then > > >>> > > > I created a file gallery and gave to the > authors > > >>> > group the > > >>> > > permissions > > >>> > > > tiki_p_upload_files, > tiki_p_list_file_galleries, > > >>> > > tiki_p_view_file_gallery > > >>> > > > and tiki_p_download_files only on this gallery. > > >>> > Also I > > >>> > > uploaded a file to > > >>> > > > the gallery using the admin user. > > >>> > > > > > >>> > > > The "author" user is able to see the gallery > but > > >>> > not its > > >>> > > contents. In other > > >>> > > > words, he can see the gallery page (instead of > a > > >>> > permission > > >>> > > denied page) but > > >>> > > > not the files that belongs to this gallery. The > > >>> > table that > > >>> > > list the files is > > >>> > > > empty with a "No records found message". Even > if I > > >>> > gave all > > >>> > > the file gallery > > >>> > > > related permissions to this user in this > gallery > > >>> > he is > > >>> > > unable to see the > > >>> > > > files. The "author" user has the permission to > > >>> > upload files > > >>> > > to the gallery > > >>> > > > and is able to do so. But he is unable to see > even > > >>> > the files > > >>> > > uploaded by > > >>> > > > himself. > > >>> > > > > > >>> > > > Am I missing something? Has anyone experienced > > >>> > anything > > >>> > > similar in 4.2 > > >>> > > > version or in other versions? > > >>> > > > > > >>> > > > Tomorrow I hope to have some time to look at > the > > >>> > code and > > >>> > > try to understand > > >>> > > > what is happening. > > >>> > > > > > >>> > > > Thanks, Rodrigo. > > >>> > > > > > >>> > > > > > >>> > > > > >>> > > > > >>> > > > > > >>> > > > > >>> > > ------------------------------------------------------------------------------ > > >>> > > > Download Intel® Parallel Studio Eval > > >>> > > > Try the new software tools for yourself. Speed > > >>> > compiling, > > >>> > > find bugs > > >>> > > > proactively, and fine-tune applications for > > >>> > parallel > > >>> > > performance. > > >>> > > > See why Intel Parallel Studio got high marks > > >>> > during beta. > > >>> > > > http://p.sf.net/sfu/intel-sw-dev > > >>> > > > _______________________________________________ > > >>> > > > Tikiwiki-devel mailing list > > >>> > > > Tik...@li... > > >>> > > > > > >>> > > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel > > >>> > > > > > >>> > > > > > >>> > > > > >>> > > > > >>> > > ------------------------------------------------------------------------------ > > >>> > > Download Intel® Parallel Studio Eval > > >>> > > Try the new software tools for yourself. Speed > > >>> > compiling, find > > >>> > > bugs > > >>> > > proactively, and fine-tune applications for > parallel > > >>> > > performance. > > >>> > > See why Intel Parallel Studio got high marks > during > > >>> > beta. > > >>> > > http://p.sf.net/sfu/intel-sw-dev > > >>> > > _______________________________________________ > > >>> > > Tikiwiki-devel mailing list > > >>> > > Tik...@li... > > >>> > > > > >>> > > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > ------------------------------------------------------------------------------ > > >>> > > Download Intel® Parallel Studio Eval > > >>> > > Try the new software tools for yourself. Speed compiling, > > >>> > find bugs > > >>> > > proactively, and fine-tune applications for parallel > > >>> > performance. > > >>> > > See why Intel Parallel Studio got high marks during beta. > > >>> > > http://p.sf.net/sfu/intel-sw-dev > > >>> > > _______________________________________________ > > >>> > Tikiwiki-devel mailing list > > >>> > Tik...@li... > > >>> > > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel > > >>> > > > >>> > > > >>> > > > >>> > > ------------------------------------------------------------------------------ > > >>> > Download Intel® Parallel Studio Eval > > >>> > Try the new software tools for yourself. Speed compiling, > find > > >>> > bugs > > >>> > proactively, and fine-tune applications for parallel > > >>> > performance. > > >>> > See why Intel Parallel Studio got high marks during beta. > > >>> > http://p.sf.net/sfu/intel-sw-dev > > >>> > _______________________________________________ > > >>> > Tikiwiki-devel mailing list > > >>> > Tik...@li... > > >>> > > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel > > >>> > > > >>> > > > >>> > > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > ------------------------------------------------------------------------------ > > >>> > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> Tikiwiki-devel mailing list > > >>> > > >>> Tik...@li... > > >>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel > > >>> > > >>> > > >>> > > >> > > >> > --------------------------------------------------------------------------- > > >> Freehosting PIPNI - http://www.pipni.cz/ > > >> > > >> > > >> > > >> > ------------------------------------------------------------------------------ > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> Tikiwiki-devel mailing list > > >> > > >> Tik...@li... > > >> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel > > >> > > >> > > >> > > > > ------------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > Tikiwiki-devel mailing list > > > Tik...@li... > > > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel > > > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > Tikiwiki-devel mailing list > > Tik...@li... > > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Tikiwiki-devel mailing list > Tik...@li... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel > |