nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Invite User permissions - Lock to a 'share site'

jollymon

I need to have users that I invite for a site only able to access that site. I cant have them in the repository, messing with things. I'm on 3.4.d

I would have thought there would be a security model builder or something in Alf for this.

Find more posts tagged with

Comments

jpotts

I think the right thing to do is to make your site private, then remove "Everyone" from Company Home. However, on testing this with Community 4.0.d, I'm seeing that the non-admin user has problems with Share when the Everyone group is removed from Company Home. You might see if that is the case on 3.4.d. That seems like a bug to me so I'll check Jira and see if it has been reported as such. (Didn't see one so I created this).

Regardless, with this approach, users will still see the "Repository" link but at least they won't be able to change anything.

If you really want to remove the Repository link, remove it. The Repository link used to be off by default and you had to make a config change to get it to show up. Now it is turned on by default. What I don't know off the top of my head is if that config is still there to allow you to turn it off without much work.

Jeff

jollymon

Jeff,

I concur that having this set to show by default in production environments could allow for additional administration headaches. I was thinking of using some css inserts to display:none the div for certain users also as a potential, however I dont see the modeled code differing from user to administrator for that diff. to happen. I had spent yesterday trying to get the latest base x32 inplace upgrade with lucene (solr disabled) running but it kept failing at import of alf_data. At the moment I am still stuck with 3.4.d but cant wait to get the drag and drop, psd/ai preview functions of the latest releases in place for my team.

I followed up on the Jira.

Thanks,

-J

jollymon

Scary, I just did this and it does not disable the persons ability to search for other sites, join unmoderated sites, search for files, download files, create new sites and who knows what else. I must be missing something major about this security model cause no way is this ready for an enterprise admin/user out of the box. This is inside in 3.4.d. I must be missing something major I am not doing.

jpotts

persons ability to search for other sites

People cannot search for or find private sites. All other sites are searchable. If someone doesn't want their site to be found, they should make it private.

join unmoderated sites

Correct, an unmoderated site is, by definition, not moderated. Anyone can join it. See previous point if you don't want that to be the case.

search for files

People can only search for and find files they have access to. If you have a file that should be private, set the permissions appropriately.

download files

The application assumes that if you can read it you can download it. This is fine for the vast majority of users, but for some people that is not a safe assumption. Letting someone read a document in the application but not download it can be achieved through a customization. Several people have implemented this. This would probably be a nice addition to the product.

create new sites

The application assumes that everyone in your organization is able to create a site. This is another example where we chose the most likely scenario, but it may not work for you. If you want to restrict who can create a site, you can do that through customization. This would also be a nice addition to the product.

In summary, the security model is the same security model in the underlying repo you are used to–Share doesn't change anything about that. You can set permissions on folders and objects in those folders as you see fit. The ability to search for sites, join sites, and create new sites really has nothing to do with the security model–that's application logic. And it is all customizable. So it may not be ready for you, specifically, to use out-of-the-box based on your requirements, but it works fine for thousands of others.

What I like about it is that if you don't like how Share works you can either use the extension points to customize it, or, you have all of the source so you can make more significant changes if that's what you need to do. Or if Share isn't going to work out, build your own app on top of Alfresco, or use some other collaboration platform on top of Alfresco, etc.

Jeff