I have a rails 4 app which contains a model called Projects.
The Projects model has publication options which allow project creators to make the project public, private, or to make a teaser version of the project public.
If the third option is selected, then some but not all of the project details will be visible to some users, whilst the full project will be visible to other users.
How do I approach this? If I create a second layout for the partially disclosed version, can I then yield some of the model attributes and not others? Is there a better way to go about this?
Thank you
I would go about using view based conditions. It gives you one file to edit and adjust for the future and will only render the information that you want the users to be able to access.
- if project.private or project.teaser
#this is my private or teaser information
- if project.private
#this is my private information
#this is my public information
Related
I'm creating an internal CMS blog site using Umbraco 7. We need to show the content based on member's language preferences. Every member has to login to the site to view the blog content. Therefore I'm using Umbraco member functionality to cater that scenario.
I noticed there is a language selection while creating users for the back-office. Also, I'm aware of creating multiple site contents to support each language.
I went though https://our.umbraco.com/documentation/tutorials/multilanguage-setup/ article. But this is not what I'm looking for.
Are there any other way to specify Mermeber's language preference and show the content based on that after login to the system?
Or any other thoughts?
You could add a "Preferred Language" property to your Member type (just a Content Picker I guess). Then you would have to do something in the front-end as well, perhaps like this: https://24days.in/umbraco-cms/2014/razor-language-switcher/ . You'd also have to add code that updates the member property to whichever start node whenever a new one is selected, as well as a redirect mechanism so whenever a member enters the site they'd end up on the correct site.
If you're asking if all this exists already - in a package or something - I don't think so :-/
I am building an e-commerce site using spree. I am new to Ruby/RoR and Spree, though not to programming and web development.
I am still carrying out research on logistics, pricing, which products to actually stock up on etc., so I simply want to display product information, and not the price and/or ability to purchase.
I have searched extensively online (to no avail), on how to do the following things I ave listed below:
I want to know how (perhaps, this requires code modification):
NOT show the price of products ANYWHERE on the site (including the product page)
On the product page, NOT show the 'Add to Cart' button
On the product page, SHOW a form that allows the user to register to the site, so that they can be contacted when the product becomes available
I am not looking for detailed steps, simply guidelines that I can follow to make the appropriate changes to the configuration (or code - if required), in order to meet these requirements.
You're going to need to override the view templates.
Try running bundle show spree or bundle open spree if you have an editor setup for bundle, this way you'll know which file you need to change. Its likely going to be somewhere here or in one of the partials, look around.
Then you can override it with deface, see Spree Docs here
If you want override the whole file, then just create the file in your app, for example, if you wanted to override spree/frontend/app/views/spree/products/show.html.erb from the gem.
You'd create the same file with your custom code in it, make sure to follow the same path and naming.
I have an application which is centered around data per 'team'. A user belongs to a team and if they log in they only see that team's data.
However, I now have super users who essentially belong to more than one team. These users should be able to log in to the system and then immediately choose which team they are interested in. From then on they will essentially view/create data against that selected team. They should also have the option to go and change what team they are viewing at any time.
I've established that the user would like to be able to have multiple tabs open and be viewing a different team in each tab.
I'm struggling to work out the best way to accomplish this with .NET MVC while keeping it as stateless and testable as possible.
I've been reading up on the different ways to persist data - session state and cookies seem to get a bad rep in MVC. TempData, ViewBag seem to focus on just persisting data for one request.
I wouldn't have thought that this is an uncommon requirement in an application - are there known patterns for dealing with this in MVC which I have missed?
So far I'm trying to create a partial view which I can show on each page to let the user see what team they are viewing the site as, and change it from there.
Any advice is appreciated!
If you want to let your superuser view multiple teams data then you'll want to pass the team information in on the request, on the query string or as something that looks like a restful url:
/blueteam/members
In fact it would be extra work to track this in a stateful manner as you'd have track user, team, and ui element when a superuser can view multiple team data at once.
I'd say passing the information in on every request is a pretty standard approach to your situation.
The tricky part of the stateless approach is decorating all your internal application links with the team information without too much extra work. Relative links can be your friends here. So a link to the bug page for a team might be to simply "bugs", picking up the team name higher in the uri path. If you are creating something that looks like a one page application it's easy enough to store the team info on the client.
If you don't want team members to see data for other team members, you can set up guard functions that check for team membership for certain classes of users before rendering a view.
I want to handle two kinds of global configuration settings:
Settings which can be altered by the user, like if notification mails for certain events are sent or not.
Settings which are tied to a specific product edition, like disabling a feature in a free version, which is only available in the commercial version.
What's the best way to store these settings? Database, configuration file, hardcoded in the source, ...?
For both cases database. You're going to be using the same structures for multiple people/products so it makes sense. Also it allows you to change things without restarting the server.
I've handled it this way in the past:
For settings specific to the user, I've created a UserSettings model/table, that has a one-to-one to relationship with a user. The reasoning for this is that the majority of my operations involving users do no not require these settings to be loaded, so they're only included on user loads from the database when I need them.
When I do this, I'll usually group my column names, so that I can write helpers that dynamically create based on the names. Meaning that I won't have to modify my views to incorporate new settings unless I add one with a different naming scheme.
For the settings specific to a product, well that depends on how you are doing things. And there are a couple of ways to interpret your question.
The way I read it is that you want to decide on a product level. What settings users can overriding or disabling a user's setting. And possibly define some product specific settings.
I would use a one-to-many product to setting relationship. The setting table would be something simplistic (product_id, setting_name, setting_default_value, allow_user_change)
This does a number of things. It lets you have a variable list of settings for different products (Perfect for the case where you're offering many different products instead of varying tiers of access to services). It also lets you define what settings a user can/can't change and give values for that product type. That can be changed from an administrator view without restarting the application. It's also not tied to user settings, to the point where if a user doesn't have a setting listed in the product_settings there will be no problems.
The downside is you will have multiple common settings in this table. I would move settings that every product will have a different value to a field in the product table.
You will also have to write validations to ensure that a user does not change a setting their product says they can't. You will also have to write helper methods to merge settings from the product and user sides.
class Flag < ActiveRecord::Base
# id, user_id, name, value (serialized probably)
belongs_to :user
DEFAULTS = {
"newsletter" => false
}
def self.lookup(user, flag)
# Please involve memcached here
case flag
when "ssl_enabled"
# Check if user has paid for sufficient access to SSL
return false
else
stored_flag = self.find_by_user_id_and_name(user.id, flag)
if stored_flag
return stored_flag.value
else
return DEFAULTS[flag]
end
end
end
end
class User < ActiveRecord::Base
has_many :flags
def flag(name)
return Flag.lookup(self, name)
end
end
For stuff that's product edition based, you probably can't really store things in the database, because the flag is going to be based on some piece of authorization code, rather than static data.
Here's my experience with this kind of stuff: don't override behavior.
You see, your first thought is going to be something like this:
Hmm.... There are system-wide settings that may or may not be overridden by users (or products). Hey! I know this! It's composition!
And technically, you'd be correct. So, you'll make a Settings table and put all your settings in there. And then you'll have a user_settings table, where you will override those settings if the user so decides. And it'll work fine.
Until you add a setting to one table and not the other.
Or you get a bug that Setting X can't be overridden at the user or product level and it takes more than 5 seconds to figure out exactly where that setting is set.
And then you'll realize:
Hey, I'm keeping track of all these settings in at least two different places. That seems kinda dumb.
And you'd be right.
So, yes. Go ahead and keep the settings in the DB, but save them distinctly for each user or product. Use smart default values on row creation and it'll keep things nice and simple.
For the first kind of settings, I would keep them in the User model (Users table).
The second kind of settings, would go to the database again. For example if a user had a free account, that would be somehow saved in the database. I would have some helpers in Application, for example "free?" or "commercial?". These helpers could find out if they are true or false, asking the currently connected User/Account model. You could then use these helpers across different parts in your application to decide if you show or hide certain functionality.
I'm working on an umbraco website just now and one of the requirements is to have a custom section in the back end that can be used to manage publish smaller micro-sites.
I have been able to create the new section and added some nodes to it. What I can't get to work is publishing them and making them viewable at the correct url.
As an example, say i have created a new section called microsite, inside that there is a folder called myportfolio. this should route to something like www.myumbracosite.com/microsite/myportfolio.
Does anyone know how to get this sort of thing working? Is it even possible to publish content from outsite of the main content section?
Any help would be greatly apprechiated.
Kind Regards
Colin G
From my understanding the custom sections are for linking to custom databases or data somewhere that needs an interface.
That said, you can use UrlRewriting and an existing content page with a macro to do something like that.
If you had a page called microsite, then using UrlRewriting you could make the parameter passed in to microsite.aspx (a content page in Umbraco) be "myportfolio".
With a user control on the microsite template it could display some content from your external database (or wherever your custom section stores it).
Not sure that's what you're looking for...
Why are you trying to create a new section for more content? The current Umbraco content area has all kinds of permissions for both users and members. Are the microsites all in the same install of Umbraco?
Another option is that the custom section could simply be used as a setup wizard for the new sites. You could create new content and users in their normal places and just use the new section to create them. It's not too hard to create content from C#, so it would probably be the same as doing it from a user control.
Could you provide a little more info?