Folder creation depends on "administer webfm" instead of "webfm upload"

I have noticed this too. Would be very useful for the option to allow upload user to create folders, or have as seperate permission.

The new maintainer doesn't seem to have time so I would encourage you to submit a patch. If it works as it should I'll quickly review and commit. I really don't want to get sucked back into this project but I hate seeing it miss out on sensible fixes.

I had a look at this while making the 5.x--2-2 release and it isn't as trivial as I thought. Definitely doable but I won't be doing it anytime soon - if ever (I was supposed to have quit this project).

I have exactly the same problem. Is there any solution by this time?

I second this - any movement on a patch? I need certain users to be able to create directories as well.

I too would really like a patch to allow folder creation.

Yes, a new class of privilege would be required however my post on Dec30 still stands. Patches are always welcome but I warn anyone going this route that it will be a lot of work.

hi, I recently worked with this problem and I solved it (for the drupal 6 version), I have the module hacked, well it lacks the permission option for create directories per role but that will be easy in the current state, so here I list what the changes are:

-Any registered user can create folders
-The created folders are associated with the user that created it
-Only the admin and the user owners can move, rename or delete their directories
-The pop up options are restricted per owner (like it is in the case of files)

I don't know if is needed the restriction to create subdirectories in a given directory only if the user is the owner of the parent directory (obviously with the exception of root directories)

If anyone is interested I can in a future make the patch, regards

I made a patch to add the functionality, is for the 6.x-2.11 version
of the webfm module (submitted on 2009-Aug-19). Only apply it on the webfm root directory

The features that adds are:

* Permission "create directory" that enables the given role to create
directories
* Deletions, movements and re-namings for only own directories (this applies per user), obviously with the exception of webfm administers
* Shows the owner of the directory in the given column
* The pop-up menus show the options that are expected

Extra information for some decisions :

* A given user can upload files and create sub-directories on another
user directory (but the parent owner of the tree can delete all the
files if she deletes her parent directory)
* If the "create directory" permission is removed from a given role
and a user of that given role has a directory, such user is allowed
to delete, move or re-name her directory.
* If you grant the "administer webfm" to a given role you also need to grant the "create directory" permission if you want that such
administer is able to create directories, all the other
capacities for the administer are the same
* The modification adds a new schema, if you don't want to reinstall
the module (if you already install it), you can add the schema manually, see the patch file for the information needed to add
"webfm_directory" schema

Well that's all, regards

I made another patch to fix an issue, the issue was that the icons to add things to the database appears to the users with "create directory" permission, here it is:

Hi, thaks for the comment, to apply the patch just do this:

cd to the root of your new webfm directory
put this command
patch -p5 < /path/toWebfm.patch
if the prompt say something like
Reversed (or previously applied) patch detected! Assume -R? [n]
just type "y" and enter, this message will be prompted like four times

I hope this work for you, regards

I'm thinking if with "icons" you refer to the pop-up icons; or what
kind of icons?, if you don't see the icons of the pop-up menu is
probably 'cause the patch wasn't applied recursively, and the file
called webfm.js (on the directory called js) wasn't modified, check if
this file was changed, regards

That's weird, I tested the patch in a brand new drupal installation and runs well, but can you please be more specific?, I mean, the pop-up option to rename appears?, appears but when clicked appears a permission denied message?, please elaborate a little more, regards

(Please read carefully all the next lines before you take any action)
Well I know what's your problem, the problem is that you don't have the "webfm_directory" schema in your data base, that's because the webfm.install wasn't executed (That's because you're putting the patched webfm module in an installation of drupal that already installed a previews version of the module) (note that I warn about this in #10). What you can do is:
1) add manually the schema to the database or
2) Go to modules, unmark webfm, save the changes, go to uninstall (on modules as well), uninstall webfm (while uninstalling a couple of errors will appear, that's normal), then on modules mark again the webfm module and save the changes, this will cause that the modified webfm.install runs.

An advise: the option number 2 is risky because will drop all the associations between files and directories already created, if you don't have anything in your webfm directories you can use this option.
I personally recommend the option number 1 since it won't have impact on the current state of your repository.

To facilitate the things, you only need to put this on your database (I'm assuming that you're using mysql):
create table webfm_directory(path mediumtext not null,uid int(10) unsigned not null default 0);

Well I hope this serve to you, regards

You might want to revise the patch to include a webfm_update_#### function that creates this table in the webfm.install code. This would let people easily upgrade without knowing SQL. See the hook_update_N API docs for details.

Thanks for the patch. I'll try this out soon and get back with my opinion. Adding a directory table seems logical but I need to audit the overall effect on the module. I'd appreciate feedback from others about unforeseen consequences or benefits for users.

I intend on releasing a 2.12 soon to roll up some minor fixes - it won't contain large changes such as this one so unfortunately you will have to repatch.

Thanks for the comment, I don't knew about this (I mean #22), I'm gonna update the patch soon. And I don't mind the re patch thing, actually the version I uploaded was an update of my original modification in the previews version (thanks emacs for doing the work easy). Regards

robmilne, since you didn't add this functionality into 6.x-2.12, can we expect to see it in 6.x-2.13? A lot of people need this. There are similar open tickets about the same feature request:
#394570: New Directory create/manage permission , #536452: New PERM for "Create directories"

I updated the patch, and I added an update hook to add the extra schema if you already installed the module.

Here the instructions to apply correctly the patch:

cd /path/webfm   (root webfm)
patch -p0 < /path/to/webfm6.x-2.12.patch 

Optionally:
If you already have installed the module you need to go to
http://yourSite/update.php
then you select the webfm updates and mark the update "666"

For more information about the patch see #10

I've spent a few hours looking at the patch. I will not commit it because it breaks the module. My primary issue is the ability of a user with a 'create directory' permission to delete/move the files of other users of the same role. This is the prerogative of module administrators but putting that power in the hands of a 'user' is outside of my definition of what a user is. If roles contained only a single user then your scheme would be fine.

In other posts I've mentioned the possibility of inventing a 'role' administrator but that wouldn't require the addition of a directory table. A user with that permission would simply be an administrator with scope limited to a role root directory and its sub-directories.

Well, my patch doesn't really do what you claim (well I think so :) ), the user only can move, rename or eliminate their own directories (the schema is for that), and all the other file behaviour is the same. Well in fact a user can eliminate the files of another user indirectly, that can happen if a user uploads files in a directory owned by other user and then the directory owner deletes her directory, but I think you aren't referring to that. If I'm missing something please tell me, maybe I can fix it, regards

Yes, I am referring to that. A person with 'access webfm' permission can upload files to any directory they can see, including, according to your scheme, directories owned by other users. It is the mixing of responsibility that I find unacceptable. Are your users admins or aren't they?

Also the function changePathRecursively is problematic because of the 'like' in the select query. How would it handle cases where a directory name occurs twice in the path where only one instance is owned by the user? There is currently nothing in the module that stops the following path from being constructed by a user with your privilege...

webfm/user/webfm/user

...where the the first instance of 'webfm/user' are the module root and role root created by the site admin, and the second instance is a hoax. I haven't actually tested your code but it doesn't pass my sniff test.

I'm setting this to postponed. I'm not averse to the concept of a 'local' admin that has directory crud capability but this implementation is not what I have in mind.

Just like to let you know that I really like your patch.... Saved me a lots of trouble! Thanks!!

Hi,

Thank you for the patch too !

Just one question : How can i disable the right click for an anonymous user ?

> At the moment an anonymous user can rename/delete/move any files in webfm, this is not cool !

sub

I know this hasn't been addressed in a while, but it is still a feature we need.

Has any progress been made on implementing the ability for users to create folders without having complete webfm admin access?

We are using 6.x-2.15 right now.

Problems applying the patch from #26 to 2.18.

Patch failed, so I manually updated the necessary files. I've attached the updated (2.18, post-patch) versions of the files. Here's the patch output:

patching file ./js/webfm.js
Hunk #1 FAILED at 383.
Hunk #2 FAILED at 868.
Hunk #3 FAILED at 887.
Hunk #4 FAILED at 1032.
Hunk #5 succeeded at 1229 with fuzz 2 (offset 187 lines).
Hunk #6 FAILED at 1085.
Hunk #7 FAILED at 2086.
6 out of 7 hunks FAILED -- saving rejects to file ./js/webfm.js.rej
patching file ./webfm_file.inc
Hunk #1 FAILED at 55.
Hunk #2 FAILED at 91.
Hunk #3 FAILED at 271.
3 out of 3 hunks FAILED -- saving rejects to file ./webfm_file.inc.rej
patching file ./webfm.install
Hunk #1 succeeded at 96 with fuzz 1 (offset 7 lines).
Hunk #2 succeeded at 121 (offset 7 lines).
patching file ./webfm.module
Hunk #1 succeeded at 149 (offset -4 lines).
Hunk #2 FAILED at 1022.
Hunk #3 FAILED at 1071.
Hunk #4 FAILED at 1079.
Hunk #5 FAILED at 1100.
Hunk #6 FAILED at 1736.
Hunk #7 FAILED at 2015.
6 out of 7 hunks FAILED -- saving rejects to file ./webfm.module.rej

Unfortunately, that's not the only issue. This was an existing WebFM installation. I ran update.php after updating the files, & "rev666" completed successfully. However, I am unable to rename directories. I checked my database, & the webfm_directory table is indeed there, & populating. I can now create directories as an authenticated user, but I can't rename them. Upon creation of a new directory, it's simply called "new_folder." The edit dialog doesn't appear on creation, nor do I get an option to rename on right-click.

It's entirely possible I've botched the patch process - there were definite differences in the code; especially the inline js in the .module file. I'm really close here, though. Would appreciate any help.

Any news on this being added to WebFM