Does this module support organic groups? For example, could I have a document repository for each group, only accessible by group members? And, ideally, a site-wide document repository accessible by everyone?

If there's no simple answer, perhaps this is a better question: How does Drupal see the repository / files? Is the repository a node or a view? Are the files nodes?

Thanks! Really excited for your module to develop, especially with a native windows client.


danreb’s picture

+1 subscribe...

christefano’s picture

I'm not a fan of the interstitial progress messages but at a glance I think this a very impressive module.

OG-specific filedepots would be nice.

thomasmuirhead’s picture

Just to throw in my support for this being made available to Open Atrium somehow.

bohz’s picture

I really look forward to test this - very needed - module.
Thank you!!

blainelang’s picture

The first release of this module does not support OG but I would like to. It was considered and time was spent time investigating. It was decided to push that feature out for the first release but made support for it in the module's permission logic.

Presently you can assign view, upload (moderated or not) and admin permissions to a group of users or roles and combination of both to individual folders. You can have any number of subfolders so the permissions can get more restrictive if you want for subfolders. You can inherit parent folder permissions and over ride them as needed. Default permissions are setup in the module admin and that includes the anonymous user role.

If you want to run a test to load dummy data to see how it looks or performs with many folders and files, use {siteurl}/index.php?q=filedepot_createtestrecords. Settings for how many folders, and files can be changed in lib-test.php. You can safely run this multiple times. Note this is just data, no real file if you try to download one of the file listing records.

The dupal_message that is set when folders are created should likely be removed - more or less it was me testing this feature out.

Appreciate the feedback ... more please :)

jacobson’s picture

+1 for Open Atrium support.

pdrake’s picture

If someone makes this OG-aware (or points me in the correct direction to do so myself), I would be glad to build an Open Atrium feature.

blainelang’s picture

We should have news shortly about filedepot and Open Atrium ....

obrienmd’s picture

Very cool, I'm really interested in this especially with a decent windows client w/ transparent saving!

Hope you can make good use of Atrium's built-in modal windows (palette), and otherwise integrate cleanly with their phenomenal UX.

blainelang’s picture

Does filedepot need to support OG for it to work with Open Atrium?

We are looking into setting up a feature server and creating an Open Atrium Feature for filedepot.

tnightingale’s picture

subscribing ...

BenK’s picture

Subscribing... I'm also interested in support for individual users having their own file depot. Ideally, I'd love to see a permissions system so that an individual user can keep their own repository of documents that only the user can see. Subsequently, that user would be able to grant permissions to others (via groups, roles, or friends) to view a particular document in their personal repository.

blainelang’s picture

Ben, filedepot supports that now. You can grant a user or role folder-admin permission to a folder or subfolder. That user or role can then create additional subfolders as needed and manage the permissions/access to these folders. They can even delegate other users as folder-admins to folders they created.

Only thing missing is support for Organic Groups in addition to assigning permissions by user and role.

BenK’s picture

Blaine, thanks for the clarification. Very cool. Looking forward to installing and testing this module.

So does that mean that an authenticated user can, by default, have folder-admin permission for their own personal user folder (without a site administrator having to manually grant them this permission)? What I'm trying to do is create a default personal folder for a user automatically upon registration (or possibly once they upload their first document)... and also automatically grant the user folder-admin rights for this default personal folder.

And given that Open Atrium is using Drupal 6, do you plan sticking with the D6 version for development? Or do you have interest in a Drupal 7 version in the not-too-distant future?

Sorry to take this thread a bit off-topic... if you'd rather have me post a new thread, just let me know.


blainelang’s picture

Hi Ben,

There presently is not a feature to automatically create a personal folder for users but can see that in some cases that would be a nice to have. There could also be a problem with larger deployments if there ends up being 500 folders where only a small % are used making it hard to find content.

Maybe if there was an assigned 'User Share' folder that would let users create one new folder only but not see other user folders unless those users had changed the default permissions. Default would be for this one new folder to be created private. Maybe the best idea is to hook into the users 'my account' and have a 'create personal folder' button if the folder does not yet exist. If the folder exists, then let them modify the access permissions right there under 'My Account'. Once the initial user folder is created -- they can create any number of subfolders but would need to use the native filedepot interface.

sparklet’s picture

How is that OA feature going - saw a screensh ot posted by Dev Seed leader Eric Gunderson. Really hanging out for this one :)

batje’s picture


tdombos’s picture


blainelang’s picture

I have been looking into integrating Organic Groups and using filedepot in Open Atrium, and have just committed changes to CVS that support the Open Atrium CSS. The module works as is in Open Atrium but understand support for OG is a strong need.

My focus right now is addressing any serious issues and bugs preventing a final 1.0 release and then I can look at adding new functionality like OG support which is at the top of the plan for a 1.1 release.

blainelang’s picture

I have an integration with Open Atrium and Organic Groups working but am debating if I should include this change in the next release candidate (normally just bug fixes and not new features).

Here is a screenshot of the changes made to the filedepot folder permissions screen.

Any combination of user, group or role permissions can be assigned and supports multiple records of each type. Only Groups the user is a member of will appear as options.

What does the community think?

sparklet’s picture

Thanks blainelang - this looks great. Clear and easy to set.

Is there any chance that you can publish your work as a feature to directly use in out of the box OA?

Thanks once again for your work:)

blainelang’s picture

If all that's needed to make filedepot work with Open Atrium is to install it as a module, what will making a feature do for the users?

In order for filedepot to work with OG, code changes are needed which means a new version of filedepot. The big question is should I wait until ver 1.1 or roll these changes into the next release candidate (which normally is reserved for just bug fixes).

izmeez’s picture

subscribing; and looking forward to testing with og

BetaTheta’s picture

I think you should roll out these changes in the next RC. I personally would love to use this feature asap. The main reason I use drupal is for OGs, so having OG support for this module would be great

ec’s picture


#20 Your screenshot looks very nice, thanks for the work done. I have a test case for the integration between filedepot and OA and I will give it a try and report back here.

Concerning the

The big question is should I wait until ver 1.1 or roll these changes into the next release candidate (which normally is reserved for just bug fixes)

IMHO, this feature could help people adopting quickly this new module, hence if the integration with OG is very ready, you should go on and put it in a new RC. If it is still not stable enough, just go on with the dev ...

My 2 cents, regards,

blainelang’s picture

Assigned: Unassigned » blainelang
Status: Active » Fixed

Added support for Organic Groups in RC3.

giannicodevico’s picture

So for the silly question, this means that Og now is a "must" to install FileDepot?

blainelang’s picture


alesr’s picture

I can set permissions for roles but I don't want to create a new role for each user group I need.
OG must be a solution to that but I don't see any "how to" or help to set this up.

Do I have to create a new content type "Group" and then set it as a Group node of OG?
How to put users in this group then and is it all manageable via UI?

blainelang’s picture

Correct - you have to setup Organic Groups outside of filedepot. You will then add as many groups as you like and members to those groups. Once one or more groups are defined, they will appear as options in the folder permissions dialog.

Setting up Organic Groups was new to me and initially confusing (ok for a while it was confusing) and I wrote a Blog Post on it last week. The how-to setup starts about 1/2 way down and there is a link at the bottom to another useful how-to article.

alesr’s picture

I got it, thanks.
To join groups and folders now you have to create them separately.
I will need to get automated folder (subfolders) creation when creating a new group.
In practice an admin will create a new group and after or between creation there will be a text entry to enter default folder names that will be created for this group.
In this case you dont put rights on created folders but you create a group with folders in it so you just need to throw some users in it and you're done.
What do you say about that @blainelang?

blainelang’s picture

I have just completed creating an Open Atrium Feature and I would like to get some OA users to test it out as it's the first feature that I have created.

You can find it on the main community server

christefano’s picture

Is Organic Groups now a dependency of Filedepot? What about site operators who want to use Filedepot but don't want Organic Groups?

blainelang’s picture

I could make it an option but need to understand if there is much demand for that - it was clear there was MUCH demand for adding OG support. If I make it an option then it effects form layout like the permissions dialog that was reformatted to make it fit as well as the obvious permissions logic.

Anything is possible.

You don't need to add any groups if you don't want to. You just need to enable the 2 OG modules.

blainelang’s picture

Version 1.1 of the OA packaged feature has been created and available on the Community Feature Server

Please review the feature release notes -- feedback from OA users appreciated.

joneslloyd’s picture

This may be an error of my own, but I've searched fairly extensively and can't find anything:

Basically, I've set up OG and FileDepot, and want to limit access to folders by two things; Admin and Group.

Admin will have full unlimited access to all folders/files, but only members of the group in question may access the respective folder for that group.

What does work is that admins can access everything. What doesn't work is the setting of permissions by group.
Members of a group can see no folders (not even those that they have full permission over).

Does anybody know why setting permission by group is being (seemingly) ignored?

I've tested this by giving permission to the individual member(s) in a group, and this works fine. I just wanted to be able to set permissions in 'bulk' by their OG membership instead.

Thanks in advance for any help.

blainelang’s picture

Are you referring to having the ability to set the default permissions for new folders to support assigning group access or the issue with 'inherit permissions' not respecting group permissions - issue 815136

Assuming your using RC3+, and your assigning the group 'view' permission from the folder admin->set permissions for a specific folder, and the user is in that group then it should work.

I am going to update the admin/settings/filedepot so that default group assignment perms can also be set. This way new folders where your not using the 'inherit perms' option can have group perms set by default as well.

joneslloyd’s picture

Possibly neither of those points actually.

Basically, my default permissions (outside of filedepot, I'm referring to the User > Permissions under Admin) can be seen ('permissions.jpg', attached), and I've allowed only access to FileDepot to authenticated users, but none of the other rights, as I don't want all users (presumably) being able to over-ride any restrictions on what they can view by being an Admin.

Then, I've set (as an example here, the folder for the OG 'Spectrum') the permissions on the folder 'Spectrum' so that only Admins and members of 'Spectrum' can exercise administrative rights over the folder in question ('folder_permissions.jpg', attached).

However, once logged in as the user 'spectrum', who is a member (and the only member) of the OG (also called 'spectrum'), I am only able to see the folder called 'spectrum', but not exercise any admin rights ('spectrum_view.jpg', attached). Furthermore, I am also able to see and access the folder of another client ('R_HOUSE'), which shouldn't happen as the permissions on that folder state that only admin and member of the OG 'R House' are allowed to view/upload (etc.) on it ('rhouse_permissions.jpg', attached).

Any help on why this is the case (and solving it) would be excellent.

Thanks for your time so far.

joneslloyd’s picture


This is increasingly looking like some newbie permissions/setup/'glaringly obvious error' on my part.

If this is the case, apologies in advance..

blainelang’s picture

No problem - will consider that you got it sorted out but if not just let us know.


joneslloyd’s picture

It's definitely not sorted!, I just meant that if you were to look at the problem I described, would you say it's an error in my set-up, rather than something fundamentally wrong with the module?

blainelang’s picture


It does look like your setup is good but I am not able to duplicate the issue. I have similar setup (different folder names and groups) and when I login as different users, they have admin access if that group has been setup and are in fact in that group. If their group does not have view access and there is no other permission (role or user) based permission setup, then that folder does not appear. I also only have filedepot.view permission assigned for authenticated role under admin->users->permissions.

I can only think there may be an issue or difference in how your groups are setup. Are you using an other group related modules like the nested groups module?

This has been tested with a default Drupal 6.16 + fildepot RC3 + OG 6.x-2.1
Also tested with Open Atrium Beta6

joneslloyd’s picture


I'm not using Nested Groups or anything that could be dodgy (as far as I'm aware!).

I'm on the Drupal RC and filedepot 3 and OG 6.x-2.1.

Not using Open Atrium however.

I've sent you a PM with other info'.


bmwelby’s picture

365.87 KB

I don't know whether this is the place to post this Blaine but I hope you can help me get to the bottom of this (I figured this is a query about OA/Filedepot integration so belongs here).

When I install and run the feature it forces the layout across the entire site to default to wide. As you may be able to make out on the attachment you can see the silver line in the background but all of the boxes are forcing themselves wide. I've set context specific views (as noted in another thread where the problem was the complete opposite of always being squashed into the 65% of the screen) but all to no avail.

I did try a completely brand new set up with fresh downloads of everything and Filedepot the only feature/module added to the base OA beta but could this be something that I've done unwittingly?

I am getting the attached error message whenever I browse to Filedepot so I don't know whether this is the problem.

Any help you can point my way would be gratefully received.


blainelang’s picture

The SQL error about the missing field groupid is either because you are not using the RC3 release or have not run the update.

Since this is a OA implementation - are you using the OA Feature that has been released on the community feature server?

mjohnq3’s picture

I've experienced the same layout problem but I haven't had a chance to 'fix' it. Disabling Filedepot returns the layout to normal.

bmwelby’s picture

yes it is the community feature server version and I will check that version - maybe in all the attempts to fix that layout problem I've not ticked all the boxes I thought I had with regards latest versions.

I'm sure you're right, so at least that's something sorted!

blainelang’s picture

mjohnq3: please ensure you are using RC3 as there are CSS and theme changes that were done to address a number of layout issues.

Testing was done on OA Beta6 with the default theme.

There is an IE related issue with the Admin Module enabled - logging into OA as a non admin and that IE issue was not present.

mjohnq3’s picture

17.64 KB

I'm using OA beta6 with filedepot rc3 and the filedepot feature 1.1 downloaded from the (your?) feature server.

The attached screen shot (Firefox 3.6.3) shows the problem.

blainelang’s picture

Uh k - I see what your referring to now. I will investigate and have a fix shortly.

blainelang’s picture

Found it -- edit the filedepot_feature.css file and remove these 2 CSS declarations

#content { width:99% !important; }
#right { display:none; }

These are needed for the Open Atrium implementation - but you can see the effect on filedepot without them. Adding these two declarations to the filedepot.css file in the module will sort this out and does not appear to effect filedepot layout in a non-openatrium (garland) site, so I will move them into the main module.

mjohnq3’s picture

Thanks very much, that took care of it.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

jpohl’s picture

This was driving me nuts. Thanks so much!

calmforce’s picture

Version: 6.x-1.0-rc1 » 6.x-1.0
Component: Miscellaneous » User interface
Category: feature » support
Status: Closed (fixed) » Active

I have installed filedepot 1.0, filedepot_features 1.1 on the top of OA alpha9, and enabled this feature. I can create a new filedepot folder from "create content", but it shows only as an entry with name and description, no YUI interface and no File Cabinet icon at the top. I spent a lot of time (added to context, etc), but couldn't make it work. I don't see it in "Spaces" config either. Was it tested with OA9? If so, what do I do wrong?


blainelang’s picture

Status: Active » Closed (fixed)

Closing this issue as it was and then re-opened with a comment that is a duplicate of issue: