When opening two browsers and editing the same page as different users, the last user who saves overwrites the other user's work without warning.
I have tried looking into workflows but there isn't a signal for when a user starts editing a page.
Is there a way to prevent the scenario described above without customising orchard?
When I was using Orchard heavily back in 2013, we added the SoNerdy.ConcurrentContent Orchard module to add this functionality. It worked well for us at the time.
Orchard has no inbuilt way to do this I'm afraid.
It is a little more complicated that it may appear I think. To implement this functionality you'd probably need to add SignalR (or some ajax polling) to monitor when a user has the editor page open. A slightly easier solution to your problem could be to create a part that checks whether the posted modified date has changed since the edit page was opened and lets the user know someone else has edited the page. They can then refresh the editor and redo their edits, not as pretty but simpler to implement.
Related
I'd like to side-step some of the security filtering done by Plone but only for people with manager or site admin roles. I want regular members to be able to add content but that content should still be filtered. Specifically at this moment I'm looking at allowing iFrames for manager role but this question is also more generic. The access to Plone that I'm referring to is a person editing a site page through Plone's standard editing system, TinyMCE.
If you look at the TinyMCE code you'll see that it load some configuration from the server. through the safe_html tranform inside the portal_transforms tool (
see https://github.com/plone/Products.TinyMCE/blob/11b957652846679cf7f441cc956730bd6fc92f87/Products/TinyMCE/utility.py#L499).
You can simply patch the getValidElements method above (adding here some user permission checking before removing/adding stripped tags) but it's not enough: this will simply change TinyMCE behavior (client side) but an evil user can access your site with TinyMCE disabled (really simple to do, just disable JavaScript in the browser), then upload a custom HTML without those filters.
So: the best thing to do is to customize the safe_html transform with the same permission checking. The simple way to add new stuff here withouy monkey-patching is to register a new plone.outputfilters adapter as described here: https://pypi.python.org/pypi/plone.outputfilters#adding-a-custom-filter
Simply patching safe_html will not work for several reasons:
html is not only filtered on save but also on display. That means that admins would see your iframe but normal users would not.
The filter is only executed once at the first display and then cached for one hour. Adding code that distinguishes between roles would have no effect on the second visitor.
this seems to be a bit of an odd requirement, but we have a separate form (not an infopath form) being filled out by people. Now, this form that we have has quite a lot of validations in it. We're currently trying to prevent people from accessing the list where this certain form is saving the data, this is so that they won't bypass the validations we created in the form that we created. Is there a way to be able to do this, one way or another?
Easy fix. Use SharePoint Designer to browse to the list, starting from "All Files". The list has several files in it. You're only interested in NewForm.aspx and EditForm.aspx.
Open these files. Either add JavaScript redirect code directly to the file (near placeholdermain) to point back to AllItems.aspx, or add a Content Query Web Part to add the redirect JavaScript code in that added web part.
Either way, when users go to add/edit items in that list, they will be bounced back to the page that list the items.
This will only work when JavaScript is enabled. Mind you, SP won't work very well with JavaScript off anyway, so people may not disable JS. But for a bullet proof solution, make a Visual Studio feature for the specific list.
First off, I am not a programmer and so I am simply trying to update an old Sharepoint site using Sharepoint tools. The difficulty I have been having is that the site has a lot of archives and pages that I don't want to recreate if possible. Therefore, I have been renaming and adding pages to an old site (originally creating via an earlier version of Sharepoint) and as I create these new pages/site within the share they look and navigate very differently from the old. How can I either update the old navigation to the new or vise versa so that the site all looks and navigates the same?
Any tips on this would be greatly appreciated
Your old pages were probably edited using SharePoint Designer and that's why they do not get the new look&feel. You could reset this changes using Site Setting Reset to Site Definition option, but it could make changes to the site you don't want (it was probably edited for a reason). I would suggest making the change on a test copy and then you will see what is changed and how it can be fixed.
This solution will allow programmers and non-programmers to work on navigation. You will be able to update the navigation using the site settings>navigation and allow the programmers to customize the styling however they wish. You can also put as many levels of sub-entres as you want.
http://sharepoint2010customnavigation.blogspot.com/
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.
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.