I am making drupal website for students on which they will be able to upload and download documents for exams. When the user registers he will be able to choose his university and type of files that he is interested at.
My question is: How can I set up that every user can see only the documents from his university?
This module do exactly what you need : Content Access
The module provides hight granularity configuration for node access permissions
Related
I have noticed that in Dropbox, you can share a file with another user, in 'read' mode, and that viewer has the ability to share that file with others via a read-only sharable link. However, in Drive, a read-only user is unable to share a link with another user at all.
Which approach would be more similar to how the Unix/Linux approach to permissions works? Why?
Try to visit the Google Drive REST API Overview in the official GDrive documentation specifically in the Share and collaborate section which was elaborated as:
apps can display a standard Google Drive sharing dialog to let users share files
What you want to do is more on Manage Sharing:
Access to files & folders is determined by an access control list
(ACL). An ACL is a list of permissions that determine whether or not
users can perform actions on a file such as read or write. See the
permissions
guide
for additional details about permissions and roles along with the
reference
guide.
Also, what want is to assign a direct file permission to the user, group or domain. It was stated to use the teamDrivePermissionDetails field to determine the use of effective role.
To see more on how to lists a file's or Team Drive permission, you can refer to the method Permissions: list
I don't really see the difference between the "repository" and "my files". They seem to have exactly the same functionalities
My Files is a unique area in Alfresco where you can create and store content, and no other Alfresco users can access it.
So rather than saving content on your laptop or tablet, you can save it in Alfresco and still keep it private until it's ready to be shared.
You can access the My Files area from anywhere in Alfresco by clicking My Files at the top of the screen.Refer this Documentation
The Repository displays all the Alfresco Content Services content that you have access to, including content of all sites that you're a member of. Refer this Documentation
Adding more : Check the same thing without admin user.You will get to know the difference.
I am new to Alfresco. Using version 5.0.d.
I am developing CMIS based application code to index and access documents into Alfresco repository.
All these documents that our application would be storing is mainly by/for our application.
So probably a limited set of users of our clients might want to manage them through Share UI.
When I go into Alfresco Share interface, I see the concept of sites.
I decided to create a site for our application.
Then inside the site, I am able to create folders
Underneath the site, I also see a document library location, inside which as well I can create folders
I am having a hard time choosing or deciding on an approach.
In order to access the 'Sample' folder that is created directly under the 'testSite' site, CMIS (Java) code looks like this:
Folder folder = (Folder) cmisSession.getObjectByPath("/Sites/testSite/Sample");
In order to access the 'TestFolder' folder that is created under the document library of the site:'testSite', CMIS (Java) code looks like this:
Folder folder = (Folder) cmisSession.getObjectByPath("/Sites/testSite/documentLibrary/TestFolder");
Code does not look any different other than the path...
Can you tell me, why would anyone would prefer to organize their folders, one way or the other?
I also do not know if this is the best way, or if there is any other way, in CMIS API to access the folders underneath a site...
You do not necessarily need to use sites to store your contents.
Sites are designed as collaboration spaces. When you use a site you get "for free":
Simplified (but sometimes not flexible enough) role based access permissions. The idea is that a site manager decides, at the site level, the role of each user. Permissions can be applied to roles instead of groups or users. This helps to simplify the administration of permissions, but sometimes is not flexible enough. Using the API or accessing the folders of the sites in the "repository view" (see for example http://docs.alfresco.com/4.2/concepts/share-repodoclib.html), you can set more granular permissions, but doing it somehow breaks the "simplified" role based permissions.
Collaboration pages: document library, blog, calendar, data lists, etc...
A site dashboard that can have a different configuration for each site and site specific dashlets
Site visibility: public, moderate, private; and the function to invite users and manage users at site level
Probably other functionality that do not come to my mind right now
As I mentioned, the "document library" is one of the pages in a site. It is designed to collaborate on contents. If you are using sites, use the document library for contents on which users will collaborate. These contents are stored in the path:
/Sites/site-name/documentLibrary/
You can definitely create contents directly in /Sites/site-name/ but it won't be visible in the "document library" page of the site. This is what Alfresco does to store other type of contents associated with a site such as: data lists, calendar events, discussions, etc...
If your repository is accessed only with a custom application by CMIS, I am not sure that you will get any benefit using sites.
I wouldn't use it if you would end up with a single site.
I would suggest to use it, if you think that it can be useful to "invite" users to sites and assign permissions based on roles.
I´m using Alfresco-LDAP to migrate all my ldap users to Alfresco service.
So far I achieve transfer all users but for every user the home folder created in Alfresco for them is his name, and what I would like, is to share a folder for all members of the ldap group, since I have multiple groups and every user of that group only can get files from that group.
This is the property
ldap.synchronization.defaultHomeFolderProvider
I read in the Alfresco documentation http://wiki.alfresco.com/wiki/Security_and_Authentication#Creating_home_spaces_-_from_1.4_onwards
But seems like what I´m trying to do is not contemplated.
Any suggestion please?
unfortunately there is no configurable HomeFolderProvider for groups supporting specific spaces. You need to crate your own HomeFolderProvider in Java for that. Out of the box you could use the companyHomeFolderProvider which is normally used if you want to disable the homefolder feature. The user object requires a userhome to be able to log in and the work around is to set the root (company_home) for that.
s.
[1] https://wiki.alfresco.com/wiki/Security_and_Authentication#Creating_home_spaces_-_from_1.4_onwards
[2] Disable the user home folder creation
Is there a Drupal module to specify access rules for specific nodes ?
I don't need to specify them for a generic content type, but for a specific node (nid).
Also I would like to specify permissions on a specific page (let's say a view).
thanks
The Content Access module allows you to specify access control per node by role, breaking it down to a granular edit, view or delete permission by role.
Views allows a permission to be set by role under the 'access' option in basic settings. You can therefore set by display giving you quite rich control over what visitors have access to by role.
I've also used Nodeaccess which may be worth looking at. I believe this allows delegation of deciding which roles may edit, delete or update a node to the node author rather than the administrator.
Views has access control built in, you can set permissions for a view from inside the Views UI. When you edit a view there is a setting "Access" where you can set a role or permission that is required to access the view.
"Content Access" has an option for node-specific access, but I never used that part of the module myself (I previously wrote Module Grants, but that functionality came from Content Access).
Other options are Taxonomy Access or TAC lite that apply permissions based on taxonomy.