I'd like to use the roles and membership ability of Orchard CMS to limit access to a staff portal in Orchard CMS. At present there doesn't look like there's an out of the box way to do it.
I've found numerous references to modules that should be able to help out but none seem to work.
Very Simple Permissions is a codeplex item suggested by some that has a dead link nowadays and doesn't seem to exist on codeplex.
Science Project: Quanta destroys my site everytime I try to install it with a missing dll issue, and not sure if its what I need anyways.
Does anyone have any guidance as to how to either: show/hide menu items based on roles using the standard menu system or advanced menu plugin
or
limit content visibility based on roles. If its a module fantastic, otherwise don't mind getting my hands dirty with some coding but a point in the right way to do this mvc style would be great. I'm going to presume I need to edit the controller for the menu module to check for current membership and adjust the view data accordingly. I'm moving away from webforms. slowly. Still getting my head around the framework.
Thanks for checking in.
For those who are still struggling with this, there's a module is called ContentPermissions which is available here:
gallery.orchardproject.net/List/Modules/Orchard.Module.Orchard.ContentPermissions
Once installed, you can then add the ContentPermissionsPart to the Content Type you want to secure.
Quanta really is what you want. You are probably missing one of its dependencies. Pete, the author, is also super-active on the CodePlex forums so if you ask there, you'll get an answer.
UPDATE: Orchard 1.5.1, the current version as I'm writing this update, supports content item permissions and menu trimming out of the box.
Related
I'm trying to create a web part that will enable users to edit items without ever leaving the AllItems.aspx page. The web part should have a similar functionality like the EditForm.aspx page.
I've created a simple web part with a ConnectionConsumer("Row") that successfully shows the selected ListItem but I'm trying to figure out how to programmatically create a form depending on the list with a save/update functionality.
I would appreciate a simple solution or a nudge in the right direction.
Thanks
What you are trying to do is not possible out of the box but it should be possible to use the SPGridView and the ListFieldIterator decorated with AJAX to get the things working as you wanted.
You can refer to the below items and build a control that does what you want.
Using SPGridView in WebParts
Articles on ListFieldIterator
ListFieldIterator
Once you build it you can try sharing the code as this is a pretty common thing everyone wants and I didn't find a good implementation of this kind so far.
This definitely sounds like a nice feature. I would love it if you could put the solution on codeplex, you're choice of course.
I've had a sneak peak on SharePoint 2010 and AJAX enabled editing is found on lots of places so I wouldn't be surprised if some kind of feature like the one you are working on will be included.
Good luck!
My customer wants to provide 2 themes for a SharePoint application. Is there a strategy to accomplish this in MOSS 2007?
We want to apply user profile-based theme selection, and maybe even a drop-down to switch modes.
I don't know how extensive you want your re-theming to be. However if it could be CSS-only you could use this approach:
Store the CSS files for the different themes in the Style Library.
Create a list that stores the user and their chosen theme.
Write a feature and custom application page to allow the user to change their theme.
Write a control that does a lookup on the list against the current user and obtains the a reference to the corresponding CSS file in the Style Library. The control would then output the CssRegistration and CssLink controls to the page for this file.
Add this control to the master page so it executes on every page (caching should be added).
I can't see why this wouldn't be supportable by Microsoft as you're only changing CSS.
If you need to do more than that then another option is to write an HTTP module that changes the HTML output. Or of course JavaScript. With these two options you may have supportability issues (it depends on how extensive your changes are).
There is also SPThemes now available on Codeplex from Bjørn Furuknap. Users can choose their own themes and they can be applied at different scopes.
Here are the options that I’ve come up with from research and feedback. Both of which seem mostly infeasible.
Implement major UI layout changes in JavaScript. This would lead to client slowdowns, would be difficult to code, and would be completely unsupported by Microsoft due to the need to reference SharePoint objects that may change with subsequent SharePoint patches.
Provide two parallel themed sites based on the same data, and provide a way to switch between them. This would require that we deploy each site to multiple locations, and would require retooling of any site creation mechanisms in code (since they'd need to target two sites instead of one).
One another thing you can try is to use the Theme Changer and ThemeChangerStaple from codeplex , That is implemented as feature you can use the same code logic to archive what you want with bit of modification, give it as an option for the user using CustomAction.
I'm not sure that there will be a definitive answer to my question, but I'd like to read some discussion from other folks on this... here's some quick background.
I'm creating a request form that will handle adding new equipment to our datacenter. I'm collecting some pretty basic info about the submitter and the equipment to add. Some of the metadata gets pretty complex, but I won't get into that here.
At first I started with a browser enabled InfoPath form, because most of our users aren't licensed for the InfoPath rich client. After much frustration I got things working, but could never get a level of performance that I was happy with. Since then I have been playing around with SharePoint's web services and I have a GREAT form that I've written in HTML (with some jQuery magic) that submits to a SharePoint list.
So now I'm asking myself... why not just use this form? First, I can get rid of InfoPath completely... that also helps us out with licensing since I won't need Enterprise licensing. Second, performance... Third, sure I have to hand code it, but I can, and I enjoy it.
So, InfoPath is out the door.
That leads to where I need some best practice ideas mixed in with new ideas. I've got this form that works great, but I want everything to work within SharePoint. As a test, I just created a new view for my list, removed the web part that shows the list, and plopped in my form. Aside from some CSS issues, everything works and it updates the list lightning quick!
But should it be a custom view? Should it live somewhere else? Should I just edit NewForm.aspx?
I'd love to hear some thoughts on this. Ultimately, my entire solution will be deployed as a Feature, but I'm not sure that's relevant.
Thanks!!
I would've done it mostly the same way:
Create a new form (via SharePoint Designer or a custom ASPX page)
Encapsulate the form in a Web Part (you can use the SmartPart Web Part if you're in a hurry)
Create as many custom views as you want, it doesn't really interfere with the way you code the form
If you must modify NewForm.aspx, don't delete the default ListForm Webpart since it's used by SharePoint for other things. You're better of just hiding it to avoid future issues.
Hope that helps
I think you should create custom form templates for your request SharePoint-List.
See MSDN: Creating Custom Form Templates.
I also recommend reading Understanding SharePoint: List Forms.
There's nothing wrong with using a custom form or a completely seperate app to edit SharePoint data. You end up with the same data you would get from using the standard new form, so it can't possibly break anything beyond the modified view.
Setting up a custom newform is probably the most appropriate place for it - easy enough to change the newform url in schema.xml or through designer.
I'm reasonably new to SharePoint 2007 and trying to move from an ASP.NET to SharePoint way of thinking has been an interesting experience!
I would like to create a page at the same level as the default.aspx page in a subsite. The "SharePoint way" of doing things involves putting the page into a document library. I am reluctant to do this as the breadcrumb navigation of the page then includes the name of the libarary but I would like the library to be transparent to the user.
I can create a page in the right place in SharePoint designer but I can't find a way to use a SharePoint template. I have tried copying the default.aspx page, but the navigation linkes are not updated.
Am I missing something or can someone suggest a solution?
I see what you are saying. I would like to share my thoughts on how I will do it.
If the Breadcrumb is your only reason why you want to move to a different than lib, the I recommend you to override the ContentPlaceholder that has the BreadCrumb in your Page, so that BreadCrumb wont be there. But URL will be there for the User to Guess ./DocLib/default.aspx.
And if the reason to hide the document library is to make sure that you don't want to allow the user to get into the Lib and change something. I recommend you strip out the permission from the Document Lib and give all the user ReadOnly and add the user with more right who you thing will need to edit the pages.
And finally you wanted to it in a Place, you can try deploying them as a Feature that will provision the pages as Ghostable rather then GhostableInLibray.
While 1,3 cab be packaged in a WSP. 2 one needs bit of a Manual / custom Code if you are trying to automate the process.
Steps to create Ghostable pages you can refer to this
It doesn't seem to be possible. Subsites can be used to be categorise content by topic, but they can't be used very much.
What is the general feeling amongst developers regarding the changing of files in the 12 hive.
For example if you were asked to remove the sign is a different user menu item, you would need to modify the relevent user control on the filesystem. Now if you just go and modify it via notepad or copy over and then if you go and bring a new server into the farm you will need to remember to do the same on the new server.
Obvouisly you could deploy the changed file as a solution and have that done automatically, but I'm just wondering if people are hesitant to make changes to the default installed files?
I have done a bit of SharePoint development, and I must tell you that messing with the 12-hive is a ticket to a world of pain if you ever want to move the app.
I'd rather hack up some javascript to hide it, at least that can be bound to the master page, which is much more portable.
And remember, you never know when the next service pack comes around and nukes your changes :)
I agree with Lars. Sometimes you will not be able to avoid it, depending on your needs. But, in general the best policy is to avoid modification if at all possible.
I know that some of the other menu items in the current user menu (change login, my settings, etc) can be changed by removing permissions from the user. Under Users and Groups there is an option for permissions. I can't remember the exact setting (develop at work, not at home), but there are reasonable descriptions next to each of the 30+ permissions. Remove it and you start hiding menu options. No modifications to the 12-hive needed.
There is a very simple rule: if you want to keep official support from Microsoft, don't change any of the files in the 12 hive that are installed by SharePoint.
I've never encountered a situation where the only solution was to change such a file. For example if you want to change an out-of-the-box user control of SharePoint, you can do so by making use of the DelegateControl, and overriding it in a feature.
More info:
http://msdn.microsoft.com/en-us/library/ms463169.aspx
http://www.devx.com/enterprise/Article/36628
I know it's tempting to quickly change a file, and I have to admit sometimes I just do that on a DEV box, but don't go there on a production server!
Not sure if there is much use pitching in, as everyone else pretty much has it covered, but I would also say don't do it. As tempting as it is, its just impossible to know the full impact of that little change you have made.
From a support perspective you will make it difficult for Microsoft support (patches/hotfixes).
From a maintenance perspective you are also opening yourself up to long term costs.
Go the javascript route.
The way to go about it is to use a Sharepoint Solution (WSP) file.
To change the user control, create a new Sharepoint feature with the new functionality.
Include this feature in your solution.
Deploy the solution either using the stsadm command line, or through Central Site Admin.
This will then get automatically deployed to all the servers in your farm, and it avoids you overwriting anything default sharepoint files.
For more info, check out Sharepoint Nuts and Bolts blog on http://www.sharepointnutsandbolts.com/ which give an introduction to WSP and Sharepoint Features.
I've done this many times and I will speak from experience: Never ever touch the onet.xml files within the 12 hive under any circumstance. Any error that you make in there, and to make the CAML even more complex the file is largely whitespace sensitive, will have an impact on every part of SharePoint.
You should also consider that aside from the substantial risk to the installation, you may well be building in dependencies upon your changes that are then over-written in a future patch or service pack.
Most of the time, you can accomplish everything you want to using features and solution packages without modifying the files. However, there are a few (rather annoying) rare cases where your only option would be to modify a file on the system. I have used it for two particular cases so far. One was to add the PDF iFilter to the docicon.xml file, and the other was to add a theme to the themes.xml file. In both cases, it seemed to be the only way to achieve the goal. Still, we used a solution package to write those files out to all the servers in the farm.