I don't think this can be done out of the box, but is there any way of protecting certain properties or whole tabs of properties in the CMS so only editors with selected roles or rights could edit them, and standard users could not (although they could happily edit other non-protected properties).
We want to protect certain content from accidental changes.
To clarify : protect some of the content on a document, not whole documents.
Is this possible?
I would rather this was done at the server level (rather than a javascript bodge to hide the tab/properties).
For now the only way to achieve something like this serverside, would be to add listeners to the ContentService save events and then check if they have tried changing any of the protected properties and then cancel the save if so.
Combining this with some kind of frontend javascript approach would most likely be best though, so the user actually knows why, when they are not permitted to save a document.
You may also be able to do something like, looping through the protected properties before the save happens and revert any potential changes back to the base document if they aren't permitted to change the property. I guess this would allow the users to actually save the document with their changes (just without the changes they made to protected properties).
Documentation on ContentService events:
https://our.umbraco.org/documentation/reference/events/contentservice-events
Related
I've got a Rails app hosted online, where the standard content has CRUD operations enabled, and multiple editors can create, edit and delete the content using controls in the views. This is working well.
There's also an About page, which contains content that mostly won't change. This is hard-coded in a view, and any changes require me to edit the view, then push the changes to the live site.
I'd like to allow the editors to edit this content online, without requiring my involvement.
Presumably the About page's content will need to be stored in the database, but it doesn't seem logical to enable the full CRUD operations on it. Eg, there will only be 1 About page, and it shouldn't be possible to delete it.
What is the preferred Rails approach for allowing the About page's mostly-static content to be editable online?
If all you want is to avoid allowing editors to delete your page, you can just avoid not putting the delete action (delete, destroy) inside your views and controllers. However, you will need to enable the create, read and update actions (CRU) , as that really is the only way to update the site remotely, short of giving them access to your app directly and having them upload it directly on to your hosting server (not recommended).
I'm assuming you already have a functioning login/authentication system, so you would simply need to just extend that functionality to the about page, by requiring the editors to login and authenticate themselves, before being allowed to perform CRUD (without the delete, D) functions.
Note that even if you were to get rid of the delete function, they could delete the about page accidentally or on purpose by simply performing an update that has nothing inside of it. You should just to be safe be saving your webpages to some sort of version control software (i.e.: Git), so that even in an event where your information gets lost, a previous backup can be used to restore your website to a previous state.
I have a system I've built in MVC 3 that currently provides a yearly submission cycle where the system proceeds through a serious of seven steps tied to dates stored in the web.config as AppSettings. However, each year, I always have to roll the system back and forth between previous steps in order to accommodate the end users. I would like to give the administrator the ability to control the system status without having to contact a developer. What is the best way to do this?
I plan to build a page with proper validation that lets the administrator set the dates. I've considered a couple options of how I should store those date, but none of them seem correct. Our entire permission system uses these dates, and various bits of text on the pages turns on and off based on what period we're currently in.
So far I've come up with two options:
Option 1: Create a database table – This was my first thought. I’ve set up properties on the MvcApplication class in the global.asax and pulled them from the database. Using a lazy loader, I can set the properties the first time they're needed. However, when they change in the database, I don't have a way to force the system to “reset” and read the date changes. If I do this action on Begin_Request(), I'm constantly opening the connection and resetting the properties for each file that the web browser opens on the server, regardless if it's static content or not.
I could directly fetch the dates from the database every time I need one of the dates, but then I'm having to redo a lot of functionality to reduce repeated database calls. I'd like to cache the dates for each request, and only pull them when I need them,
Option 2: Allow editing a config file through the application – I've looked up how to split the web.config file so I can have a separate file that just contains the appSettings. Then I could just update the new config file from a controller action. I think this would work nicely, and not require me to rewrite any of the existing functionality, but it feels like I would be introducing a bad design pattern into the code.
I'd vote for the database. For the sake of performance you can cache those parameter values in a static class inside your app and provide a method to reread them from DB in the same class. So:
When a user makes request, check if those properties are already cached. If they are - use cached values, if no - read them from DB
When administrator makes changes to those parameters - store them to database and enforce your static caching class to reread them from DB.
I would suggest an approach that doesn't care whether the settings are stored in database or key/value pairs in config file.
Since you want the settings to be accessed globally by all users you can cache the settings and the cache implementation should be generic and distributed. There are plenty of online resources available how to create such an interface.
Since you want the cache to be sync with the underlying data you have to set cache dependencies (AppFabric won't supports sql cache dependency see this thread, while NCache supports both sql and file).
I would store the values in a database and use a distributed cache to persist the data across the web farm. MS AppFabric Caching has worked well for me. You will need to implement a standard caching pattern (check the cache, if null load from db and insert into cache).I would probably just create a static Load() method that abstracts this logic away. When the admins update the db you could update the cache or just delete the cachekey.
Therr are other considerations to be added to performance. Namely if you modify the config file thr application pool is re iniyializrd, while the database solution doesnt cause application reinitialization
...so do you need to re initialize the app after the changes or not?...If there i no way to avoid the inizialization whitout drastic changmes to the application ptobably the config filr solution is better
I have an application that has different data sets depending on which company the user has currently selected (dropdown box on sidebar currently used to set a session variable).
My client has expressed a desire to have the ability to work on multiple different data sets from a single browser simultaneously. Hence, sessions no longer cut it.
Googling seems to imply get or post data along with every request is the way, which was my first guess. Is there a better/easier/rails way to achieve this?
You have a few options here, but as you point out, the session system won't work for you since it is global across all instances of the same browser.
The standard approach is to add something to the URL that identifies the context in which to execute. This could be as simple as a prefix like /companyx/users instead of /users where you're fetching the company slug and using that as a scope. Generally you do this by having a controller base class that does this work for you, then inherit from that for all other controllers that will be affected the same way.
Another approach is to move the company identifying component from the URL to the host name. This is common amongst software-as-a-service providers because it makes sharding your application much easier. Instead of myapp.com/companyx/users you'd have companyx.myapp.com/users. This has the advantage of preserving the existing URL structure, and when you have large amounts of data, you can partition your app by customer into different databases without a lot of headache.
The answer you found with tagging all the URLs using a GET token or a POST field is not going to work very well. For one, it's messy, and secondly, a site with every link being a POST is very annoying to work with as it makes navigating with the back-button or forcing a reload troublesome. The reason it has seen use is because out of the box PHP and ASP do not have support routes, so people have had to make do.
You can create a temporary database table, or use a key-value database and store all data you need in it. The uniq key can be used as a window id. Furthermore, you have to add this window id to each link. So you can receive the corresponding data for each browser tab out of the database and store it in the session, object,...
If you have an object, lets say #data, you can store it in the database using Marshal.dump and get it back with Marshal.load.
I am trying to show/load different editor on different rows of a editorgridpanel. Like a textbox on one row combobox/superboxselect on another and it could be any order, random.
The conditions which dictate which editor will be shown reside in the database.
Please tell me if this is possible and if so, how do i go about it.. I have tried pulling the conditions asynchronously which are pulled on a click event for the respective column, but calling it async causes problems. Please advise
Anything is possible, but what you want to do would take a bit of work. The basic idea would be to configure the needed grid editor(s) dynamically and update the columns with the new editors when needed. Now... what would be required to make that actually work I couldn't say offhand without digging into the Ext source -- it would almost definitely require overriding default behavior in the grid and/or column model.
Pulling your conditions asynchronously would (I imagine) be too slow for the interaction of clicking on a row to edit inline. If it takes a second or more from click to configured editors, that would not be acceptable performance. I would try to find a way to send your conditions down along with the other row data if at all possible (they can be in the store's data model on the client without having to be shown in the grid).
Without knowing more about your business requirements, it might be more appropriate to ditch the editable grid and instead go with a dynamically-configured FormPanel tied to the grid. This way the interaction of clicking and then pausing slightly while the form is configured would appear to be more natural. Also, the functionality of rendering a form with a particular configuration is perfectly standard and would require nothing fancy on your end. See this example as a starting point (your form would be dynamic, but maybe the same type of interaction could work?)
I'm developing a webapp that allows the editing of records. There is a possibility that two users could be working on the same screen at a time and I want to minimise the damage done, if they both click save.
If User1 requests the page and then makes changes to the Address, Telephone and Contact Details, but before he clicks Save, User2 requests the same page.
User1 then clicks save and the whole model is updated using TryUpdateModel(), if User2 simply appends some detail to the Notes field, when he saves, the TryUpdateModel() method will overwrite the new details User1 saved, with the old details.
I've considered storing the original values for all the model's properties in a hidden form field, and then writing a custom TryUpdateModel to only update the properties that have changed, but this feels a little too like the Viewstate we've all been more than happy to leave behind by moving to MVC.
Is there a pattern for dealing with this problem that I'm not aware of?
How would you handle it?
Update: In answer to the comments below, I'm using Entity Framework.
Anthony
Unless you have any particular requirements for what happens in this case (e.g. lock the record, which of course requires some functionality to undo the lock in the event that the user decides not to make a change) I'd suggest the normal approach is an optimistic lock:
Each update you perform should check that the record hasn't changed in the meantime.
So:
Put an integer "version" property or a guid / rowversion on the record.
Ensure this is contained in a hidden field in the html and is therefore returned with any submit;
When you perform the update, ensure that the (database) record's version/guid/rowversion still matches the value that was in the hidden field [and add 1 to the "version" integer when you do the update if you've decided to go with that manual approach.]
A similar approach is obviously to use a date/time stamp on the record, but don't do that because, to within the accuracy of your system clock, it's flawed.
[I suggest you'll find fuller explanations of the whole approach elsewhere. Certainly if you were to google for information on NHibernate's Version functionality...]
Locking modification of a page while one user is working on it is an option. This is done in some wiki software like dokuwiki. In that case it will usually use some javascript to free the lock after 5-10 minutes of inactivity so others can update it.
Another option might be storing all revisions in a database so when two users submit, both copies are saved and still exist. From there on, all you'd need to do is merge the two.
You usually don't handle this. If two users happen to edit a document at the same time and commit their updates, one of them wins and the other looses.
Resources lockout can be done with stateful desktop applications, but with web applications any lockout scheme you try to implement may only minimize the damage but not prevent it.
Don't try to write an absolutely perfect and secure application. It's already good as it is. Just use it, probably the situation won't come up at all.
If you use LINQ to SQL as your ORM it can handle the issues around changed values using the conflicts collection. However, essentially I'd agree with Mastermind's comment.