Please, someone, get recursive permissions in the Document Library portlet!

[Steve Revill, modifié il y a 12 années.]

I just uploaded a pile of directories and files into a document library via WebDav and every single one has the wrong permissions. Presumably because it doesn't honour the default permissions or inherit the permissions from the root folder. Whatever.

So I want to fix things from the web interface. BUT THERE'S NO RECURSE OPTION! WTF?

I have to use this clunky UI to correct the permissions for hundreds of files and folders. For each. And. Every. One.



Please someone tell me there's a better way.

Liferay Portal Community Edition 6.0.6 CE (Bunyan / Build 6006 / February 17, 2011)

[Rob Sneyers, modifié il y a 11 années.]

This is indeed on of the worst shortcomings of Liferay.
There should be a simple way to set the same standard permissions for every document that's uploaded to a given document library (webDav or other).

I find it shocking that no one has even replied on this topic that's been sitting here for months.

[Hitoshi Ozawa, modifié il y a 11 années.]

No, there isn't. You'll have to add your own interface. Liferay only provides basic interfaces. You'll have to add your own handy interfaces. I've been doing it and also to add compatibility with earlier versions.

[Rob Sneyers, modifié il y a 11 années.]

We're all just users. I don't have "my own interface", handy or not.
We can't all be Liferay Legends, after all.

I can only emphasize what I said before: This is one of the worst shortcomings of Liferay in every day use. This should be solved with priority. This is as basic as it gets.

[Hitoshi Ozawa, modifié il y a 11 années.]

This is one of the worst shortcomings of Liferay in every day use.

Well, it's a shortcoming, but "worst"? :-)

I've seen request for this feature before so you're not the first one. Try to get many people to vote to have this feature implemented.

[Jorge Ferrer, modifié il y a 11 années.]

Hey Rob (and Steve),

I agree with you, this should improve. The root of the issue is that it is only possible to set the default the permissions for the whole installation. But there are many cases in which that is just not enough.

What we want to do is make sure the default permissions can be set at several levels: portal instance > site > folder. When adding new documents (or content in general) the most specific default permissions that had been set would apply.

I hope that makes sense. My intention is to make sure this gets added for 6.2.

Meanwhile, one possible workaround that might be useful in some cases is to change the default permissions in resource-actions/documentlibrary.xml either permanently (if that's what you want) or only when a lot of documents are going to be uploaded.

[Hitoshi Ozawa, modifié il y a 11 années.]

Jorge, I think you're misunderstanding the requirement. It'll be nice to set default permissions, but the requirement is to be ability to have permission inherited from the parent folder. This really isn't too complicate to implement, just have to flag "inheritFromParent" and when it's true, set permission based on the parent folder.

[Dhrutika Parekh, modifié il y a 11 années.]

Hi Hitoshi,

If I am not wrong below property is for permission inheritance only

#
# Set the following to true to automatically check the view permission on
# parent categories or folders when checking the permission on an specific
# item.
#
# For example, if set to true, to be able to have access to a
# document, a user must have the view permission on the document's folder
# and all its parent folders. Or, to have access to a comment, a user must
# have the view permission on the comments's category and all its parent
# categories.
#
permissions.view.dynamic.inheritance=true

Its already there in 6.0EESP1.

Regards,
Dhrutika

[Hitoshi Ozawa, modifié il y a 11 années.]

That's just the view. Users need inheritance of other permissions as well.
If you've set permission on Windows, you'll know there are two ways. (1) To inherit during run-time and (2) to inherit during setting so the permissions will be copied.

You've also note that there are now several way to access file in Document and Media library. The topic of this thread is not just about implementing permission from the web browser but from WebDav. Uploading many files from web browser takes too much time.

[Dhrutika Parekh, modifié il y a 11 années.]

Hi Hitoshi,

Thanks for the clarification.I didn't understood it properly.

It would be gr8 feature.

Regards,
Dhrutika

[Jorge Ferrer, modifié il y a 11 années.]

Hi Hitoshi,

We have discussed a lot internally and in open forums about the concept of dynamic inheritance but it is not so clear that is a good idea in the context of Liferay. In an OS it is simpler since everything is ultimately a file and all have the same operations. Within Liferay that is not the case, there are many types of entities each with its own set of permissions. For example, a folder does not support many actions that the items within (documents, document links, bookmarks, web content, ...) may have. Furthermore, Liferay's permission system is additive, so when a permission is given (for example inherited) it cannot be taken away. Furthermore the meaning of inheritance depends on each specific portlet, so it is not so easy to generalize within the permission system itself. To add more, in general implementing inheritance is not very efficient.

Considering all this, we decided to only implement it for VIEW or ACCESS permissions which are quite generic and for specific portlets. For everything else I personally think it makes more sense to support setting defaults and also provide a way to apply any change in the defaults recursively.

Thoughts?

[Hitoshi Ozawa, modifié il y a 11 années.]

Agreed on dynamic permission. I think that why we want a way to set static permissions when uploading files. Ability to set the permission of the uploaded file/folder to be the same as that of the parent or a portlet to recursively set/change permissions on folder/files.

Well, the bottom line is, how are you going to satisfy these users' requests. I personally don't like losing sales. If people pay me, I'm willing to provide my solution to them (even though I've been restricting my clients to Japan, I can become flexible).

[Natasa Bulatovic, modifié il y a 11 années.]

This "inherited" /not inherited discussion is indeed a long one and brings no solution so far unfortunately as both users and LR people seem to have incosistent views on this topic.

I am interested about explanation, how can I inherit the privileges for all files/folders etc. defined on the folder level from the current document library?

To clarify , here is the example (6.1 ):

*On one Site page i have a portlet for document library created from a Site template
*this has predefined three top folders (under Home):
* "Site-input"
*"Site-Output",
*"Site-work"

*the site has following roles: SiteMember, SiteOwner and SiteAdministrator, and a custom role: SiteEditor
*Site editors, SiteOwners and SiteAdministrators - can edit/access/view/-> do any operations on all folders
*Site members can view/access all data in "Site-Input" and "Site-Outpur" folder, but can not view and do anything on "Site-Work" folders
*we had a requirement to "hide" the "input-permissions" and that all files inherit the permissions given on the folder level

trial 1:
=======

*After this was done, upon creation of a file, no permissions are provided except to the SiteAdmin, SiteOwner and User who created this file (these are basically default permissions)
*as we hide the "input-permissions", there is no way we can set-up the permissions again, unless we change the portlet action classes
*as a consequence, nobody but SiteAdmin, SiteOwner and User who created this file can view the file or do other operations

trial 2:
======
<input:permissions> field only shows predefined roles
*an option is to include the new roles in resource-actions of documentlibrary.xml
*but as well in this case, only predefined options and privileges are provided, and NOT the ones i have defined on portlet instance and folder level.

The idea which was quickly thrown away: redefinition of <input:permissions> tag would be pretty heavy as i could realize with a limited knowledge, as the permissions are at the end read from the serviceContext which only supports default roles (even though LR allows for custom roles)

So what to do? Would appreciate any answer or tipp ..
thank you
Natasa

[Natasa Bulatovic, modifié il y a 11 années.]

Seems that only when someone says "worst" drawback of Liferay the lights are switching on ..
At least a decent answer how to assign permissions for DL folders for roles other than custom roles would be nice .

Thanks,
Natasa

[Natasa Bulatovic, modifié il y a 11 années.]

See also the problem identified here

http://www.liferay.com/web/guest/community/forums/-/message_boards/view_message/14619181

After some debugging and testing i could realize that the famous servicecontext usage in DL content is making indeed a lot of problems.:
*there is no possibility to set special privileges for pre-defined roles such as Site member, Guest if ui:input-permissions are not populated.
Actually the values users "on-screen" selects from the permission fields are written in the service context.
After creating a new folder, my listener which gives privileges for this folder works very fine for each role except for guest (well, not important to me) or for site member

*The edit DLFolder action calls somwhere a method to set the resource permissions on this DL Folder. These are taken from the service context !!! As my input-ui permissions are not populated i used a listener and in the after-create method of the Folder i am setting separately the privileges for the Folder.
*The above action actually always resets the action-ids to 0
*my very hacky workaround solution contains another listener, on resource permissions - and resets the folder permissions again to my desired values

Cumbersome, not clear, not explained. LR states: just use the ResourcePermissionLocalServiceUtil.setResourcePermission method and all will be fine.
LR states also that the inheritance works for view/access - it does not work as soon as input-permissions are removed from the JSP page when adding a folder (same goes for files).

The listener on DLFileEntry had better behavior, at least i was allowed to set-up this privilege - but not in aftercreate, but in afterupdate method, which anyway is performed always even when the file is created.

The serviceContext is indeed a cumbersome and not enough explained, perhaps only known to LR developers.
Next, in the DLPermissions method "contains" which checks the privileges, i always get : no action "DELETE" exists on document library portlet.
The next problem is: DLFolderPermissions for top-level folder (which seems not to be a folder but a placeholder) named Home does not give me privilege for DELETE action on multiple first level folders, despite the multi-select box is displayed in the JSP always. In code which checks this privilege, it explicitely returns FALSE, even though the privilege is set to DELETE for "com.liferay.portlet.documentlibrary".

This is not consistent behavior, as for all "inheritance" issues, the mechanism need to be same - therefore even Home folder shall be a folder and not null returning folderId=0.

In this manner, only people who designed the permissionsmechanisms and those persisten to figure it out could actually do something. However please consider changing it in consistent manner- as in this case it is possible to implement unified mechanism and correct inharitance for almost all actions.

[Hitoshi Ozawa, modifié il y a 11 années.]

Seems that only when someone says "worst" drawback of Liferay the lights are switching on ..

Well, Natasa, Liferay.com seems to have their own customers to satisfy to and it's often goes against what community users desire.
They're in business so they have to priorize their paying customers before non-paying users.

At least a decent answer how to assign permissions for DL folders for roles other than custom roles would be nice .

If you can't fix it yourself, you can try getting somebody else to fix it for you. There's not such thing as free lunch.
I think liferay.com has done enough providing "decent" platform to base web system on by providing liferay community version to
the public.

This is little bit off the topic, but recently, I'm testing using catalog as a directory structure to files instead of the file structure.
The advantage of using catalogs is that I can define several so different users can navigate in different ways to a file.
Creating different catalogs based on roles and setting permission of these catalogs may provide what you've wanted to do.

[Natasa Bulatovic, modifié il y a 11 années.]

Liferay.com seems to have their own customers to satisfy to and it's often goes against what community users desire.
They're in business so they have to priorize their paying customers before non-paying users.

Hitoshi, This quest was not asking LR developers to work for a poor community customer, but for getting information from first hand - how actually privileges work. Even though open-souirce community is not a paying customer, LR gets a lot of contributions, in terms of testing, patches and features. If we thought LR is very bad, we would not have used it in first place. But one shall indeed be open for critics which are not related to custom requirements, but to general LR issue, valid for all users- including paying customers.

If you can't fix it yourself, you can try getting somebody else to fix it for you. There's not such thing as free lunch.

Thanks for this wise thought. We have fixed our issue for our requirements, but indeed the problem is in LR implementation, which supposes that all users would have to use ui:input-permissions at any time for privileges on site-members and guests in the DLFolder implementation. Maybe this could have been clarified in fact in LR documentation. My previous post explains the problem and the solution we implemented: we did not wanted to change LR sources or make extensions - due to the fact that we can not anticipate what consequences such a change would bring.

[Jorge Ferrer, modifié il y a 11 années.]

Hi Hitoshi,

Hitoshi Ozawa:

Liferay.com seems to have their own customers to satisfy to and it's often goes against what community users desire.
They're in business so they have to priorize their paying customers before non-paying users.

I would sincerely appreciate if you avoid saying things like this. I've been involved in Liferay as a project since the beginning, was a community member 4 years before I had the opportunity to join the company and have a close relationship with almost every body here and I know for a fact that nobody sees things the way you have expressed them in your sentence above. Yet, I keep seeing it in your answers all around the forum.

We work very hard both personally and as a company to deliver as good of a product as we can that is useful to as many people as possible and it is very discouraging to read such a judgement by a very active community member such as yourself.

Now, talking about me personally, I think that it does not make sense to try to satisfy customers at the expense of the community users desire. I think that only by having a great product that is useful to as many people as possible Liferay Inc can be successful as a company. Of course this is easier said that done and we want to do so many things that we wished the days had 48 hours, yet they don't. The good news is that as the company grows we are able to hire more and more people to work on the product. Not only that, but there are other companies and individuals that also contribute to the product with ideas, code, sponsorships and much more. That's the beauty of Open Source.

The topic of this thread is not an easy one. I've talked to many people about it in the forums, symposiums, calls, ... and there are lots of different opinions regarding how it should work. The goals of the leaders of any open source project in situations like this is to listen to all opinions and try to reconcile the opinions and come up with the best solution possible. However that is not always easy and takes time. I think it is not fair to misinterpret it as lack of interest.

[Hitoshi Ozawa, modifié il y a 11 années.]

Jorge, it would be better if you would comment and let us know about the status of what is going on more often because if you say something and just let it go afterward, it seems you're just neglecting it. I know that all of you are working hard, but I just can't see it. For example, the current GA2 release. This may not be your territory, but can't liferay.com tell us provide us more information about exactly what is keeping it delayed rather than just telling us just a few days before the planned delayed date that it's going to be delayed again for the same reason? James keeps telling us that we'll be impressed with the result but can't we take a peek at it beforehand? It's everything in the github?

I'm involved in other open source projects and I can see in the codes where the delay is occurring. Unfortunately, I can't with liferay.

The goals of the leaders of any open source project in situations like this is to listen to all opinions and try to reconcile the opinions and come up with the best solution possible. However that is not always easy and takes time. I think it is not fair to misinterpret it as lack of interest.

Can you bring those with opinion into the community so we can discussed it here so we'll know what others' are thinking too? I think the thread on "communtity" being renamed as "site" was very good. I think it would be better if we can have more of these kinds of discussions on the forum. The way it is now, it seems you're just trying to gather all the information yourself and then do the decision yourself and only shows community the result. I can't see where the community input is being used in the process - it seems you're ignoring us.

Lastly, I do hope that you'll consider that we are in a business too and do have commitments and deadline. If you can't tell us how long and what you're really going to do, it's very difficult to plan. I think most of us are thinking and working in much shorter time span. Looking at the number of posts you've made, it seems you've been more active in the community before than you are now. There was a comment by somebody too that liferay.com employees nowadays only seems to take notice when you complain loudly. I think all of us would appreciate if you and other developers would periodically directly tell us what you are working on now and when we can expect it rather than letting James, who I don't think is not really in development, do the announcements.

This is all happening probably because liferay community is growing rapidly. :-)

[Jorge Ferrer, modifié il y a 11 années.]

Hi Hitoshi,

I think that everything you say in this last post is completely fair. Those are all things that we need to improve on and in fact we are working hard to do so. As you mention the fact that not only the community but the company is growing rapidly makes it very challenging but of course that is not an excuse.

I honestly appreciate when community members like you highlight our deficiencies because it keeps us with the feet on the ground and tells us where we need to improve. Not only that but when the criticism comes in a nice and constructive way like in this last post it is also motivating for us. I don't know, it might be true that when people complain out loud more of the leaders end up participating because Liferay is more than a job for most (if not all) of us and we take it very seriously, but I think constructive criticism is ultimately much more effective.

In any case, point taken related to the lack of communication. Specially with the release of GA2 I think we haven't done a good job at communicating the delays and the main cause was mainly that the estimates were just too optimistic with the amount of stuff we wanted to put in (mainly fixes) as well as the interdependencies with other releases (such as Marketplace and Social Office). The changes in dates were communicated when it was decided, we didn't delay the communication on purpose. Of course that shouldn't have happened and we've taken the measures to avoid it in the future.

I will also try to help with providing more communication by getting back to blogging and twitting more often.

[Andrea Borruso, modifié il y a 10 années.]

Hi Jorge,

I hope that makes sense. My intention is to make sure this gets added for 6.2.

is there any news about permission inheritance and 6.2?

Thank you very much,

Andrea

[Jorge Ferrer, modifié il y a 10 années.]

I'm sorry to say that it didn't make it into this release. It is at this point part of the plans for 7.0.

BTW, I don't think there isn't any feature request related to this topic yet. Would you like to create one and promote it? That way anyone interested can vote for it and comment their ideas.

[Kim Zeevaarders, modifié il y a 6 années.]

Jorge Ferrer:

BTW, I don't think there isn't any feature request related to this topic yet. Would you like to create one and promote it? That way anyone interested can vote for it and comment their ideas.

Hi Jore,

I believe there is: LPS-31253

This ticket was created over 4 years ago! How is it possible that such a desired and easy to implement feature is still not available in LR7? What is even more absurd is that this ticket was "ranked lower" just one month ago. Could you please tell me why LR is so reluctant to implement this functionality? A lot of people could profit from this and are desperatly waiting for this functionality to become available

Hope to hear from you!

Regards,

KIm

[Kim Zeevaarders, modifié il y a 6 années.]

Jorge Ferrer:

What we want to do is make sure the default permissions can be set at several levels: portal instance > site > folder. When adding new documents (or content in general) the most specific default permissions that had been set would apply.
.

Hi Jorge,

Could you please tell me if LR 7 has this capability? Im struggling very much with different site admins asking for different default permissions of their document library.

Hope you can elaborate about this since it seems very basic functionality to be able to change default DL permissions on a per-site-basis. I can only set modify permissions for all sites by modifying the document-library.xml which by the way, is not recommended!

Hope to hear from you!

Regards,

Kim

[Kim Zeevaarders, modifié il y a 6 années.]

Anyone?