recently i thought to apply roles to users in a different way,without using role manager etc.like create one column named 'ROLES'...and redirect user by checking this column at login time.I know so many of you are thinking what is i am gonna do.I am also thinking the same.I know one drawback of this technique,that is one user cant have multiple roles.Is there any other drawbacks of this technique and why should this technique be avoided and one should use role manager instead of this?
Well Rohan, There is nothing wrong with your way. I have used this type of techniques for 2 years because I was too lazy to go thru the role managers and overriding it where needed.
However i feel now that I have always reinvented the wheel. Its your persective how you see that.
and your last question "why should this technique be avoided and one should use role manager instead of this?" the answer is because it is readymade and timetested. Any new code that you write has a theoritical limit that it can have bug, so suppose you have rolled out your own authentication engine- you will have to test it.. Isnt it extra efford that you have to put?
Use that Link, I think it will help you..
Related
I've assumed there was something unique or special about the default Tridion groups (e.g. Editor, Chief Editor, etc) because creating a new Publication seemed to get these groups automatically.
I actually see that new publications get all of the groups in its assigned parent upon creation, it's not necessarily because they're default groups.
Can I delete these default groups? Aside from the out-of-the-box workflow options, any reason to leave these in Tridion from a programming or technical perspective?
New Publications outside of an existing BluePrint will pick up the default rights from the default groups. If you don't need any out of the box settings, you should be OK deleting them (but I have never tried, so it may not be possible). In the database they have a special flag (IS_DEFAULT_GROUP).
I tend to use them for controlling rights, and make my other groups members of Authors,and Editors etc so that I get some basic rights out of the box for all publications.
In the original design of R5 security it was possible to delete the predefined groups, and this was intentional. If you are getting a specific message telling you it is not possible, then this constraint must have been added later, presumably as code was re-written for 2011.
The thinking back in R5 was that the predefined groups would offer a good "out-of-the-box" experience, and save people some configuration. (And of course, it offered backwards compatibility with R4.) Other features echoed this: for example, if you create a publication in a blueprint, the Rights of predefined groups are cloned from the parent publication. For groups you've created yourself, this doesn't happen. After all - if you've chosen to go for a custom security set-up it's reasonable to expect you to customise everything yourself, right?
I can't think of a good reason for preventing their deletion. Perhaps someone thought the "custom" approach was just too unfriendly, but I'm speculating. (Anyone know the real reason?)
No, it is not possible to delete a predefined group -- you will always get an error saying as much.
I can't speak as to the reasons for this, but I imagine the fact that they are used for new Publications is at least part of the reason.
You are not required to actually use them, though.
http://www.silverstripe.org/archive/show/1638
The above post seems like it's what I should do but I just need some help sorting this out in my head.
Firstly, I need to create a relationship between a page (Owner, for example) and a dataobject (Car). An owner can create many cars which are linked to that one owner. However, I have another page (Garage) which can create cars that are linked to every owner. If an owner does not want one of these cars they reject it. I was thinking the manymanydataobjectmanager would be good for that bit.
Each owner should only be able to see the cars that relate directly to them within the CMS, not other peoples cars, so I was using dataobjectmanager and assigning permissions to the page using groups.
The thing that is really making this awkward is that when it's all set up I need to output JSON which will consist of the cars the owners created and the cars they accepted from the garage, not the ones they rejected. I'm thinking I need another table like the linked table but with a status column perhaps?
To clarify, my question is how do I create this mess in a constructive SilverStripe way? Is the approach I was taking correct or is there a better way?
Many thanks in advance and please tell me if I've been unclear.
are you using silverstripe 3?
could you clarify what of the actions happen in the backend and what actions are possible for the user in the frontend?
maybe for your relations it could be better to use ModelAdmin:
http://doc.silverstripe.org/framework/en/reference/modeladmin
It gives you the opportunity to manage relations without the Sitetree/Pages Overhead. For example creating a Sitetree Element just to have an Owner is not the best way - except if you really need an Owner represented as a real Page. Owner could be also just a Dataobject instead.
Especially if you want to output just JSON in the end you are maybe completely independent of Sitetree/Pages... then you could write a custom controller with a routing rule and which gives you back just the data that you need:
http://doc.silverstripe.org/framework/en/topics/controller
regards,
Florian
I'm using jQuery, ASP.NET, SQL Server, and the other usual suspects to design a company CRM. After they put in contact info, notes, dates, places and so forth they have to be able to select many different people to be "CC'ed." A group of people will be required to be one either "CC'ed" or "ToDo." The rest of the people can be nothing or "CC" or "ToDo." Currently we have it set up as a huge databind to templates with radio buttons for each option. Looks like shit. Anyone have any suggestions? I'd like to use a template with a datasource and have a good way to retrieve their answers and use them.
I'm leaning jQuery direction but like I said I'll need there to be up to 3 possible options for the people. This is going to be all opinion so I'm just looking for options.
Just to re-clarify, this concept is similar to email but I don't want them to have to type anything in as it is a set group of names that they're allowed to select from.
Looking for quick simple and pretty. somewhere in the range of 120 names.
If you intend to look down the jQuery route, I suggest that this widget could possibly help you out (even if only for inspiration sakes). http://quasipartikel.at/multiselect/
I'm struggling to "visualize" your form for terms of "real-estate expendature" etc.
Not directly what you are looking for, but this plugin may help
http://devgrow.com/slidernav-jquery-plugin/
Typing with intellisense. Sorry - any graphical thing will look overloaded.
Or: A table with filter options on top (again, typing). THere simply is no other way.
What I would most likely do to achieve this is implement the auto filter pattern that you type in a text box a few letters of the name and then it would filter down all of the overall results to those containing that pattern. Then have a select all button that will let you check all of them, and then the user can manually uncheck a few instead of having to check all.
The other thing to do would be to offer some type of categorization of the data so that they could filter by category that would put people in probable groups that would want all them all together. Like IT, HR, Executive or something similar.
I know there are already some questions on this topic on the site...
I am just trying to understand if it's safe to use ASP.NET Profile Provider with a website with huge traffic?
The way I see it, it's laid out inefficiently. You store property name (which is a string) and property value (which is a string too). If you are just trying to store even age in the profile, you are unnecessarily storing the string "age" in the database over and over whereas with a self-created table, you could just add a column titled age, and no redundancy?
(I am just trying to make sure I am not missing something about it, because I am fairly new to it.)
The profile provider uses an EAV (Entity-Attribute-Value) design deliberately, because profiles in general very commonly have a sparsely populated schema - that is, there are many potential attributes, but only a few will be used for a given single entity, and the few that are used varies widely from one entity to the next.
Let's use a totally arbitrary example - let's say only one in 10 of your users want to provide their age. Making that a column now seems more like a waste, no?
But what if your application makes age mandatory? OK, that column gets populated for everyone. But what if you need to make a note in the profile "user doesn't want to see this obscure dialog anymore". Do you really want a column for every single dialog in your application whether a user wants to see it? Probably not. When you get into the little one-off details of an application of any significant scope, EAV actually becomes the more economical choice.
In the general, it scales quite well (far better than you probably think). In the specific, it doesn't matter - as always, use what works and fix performance problems when they come up. Whatever the scalability limitations of the profile provider are, you'll know when you hit them. I guarantee two things - (1) you'll have to fix a lot of other performance problems you didn't expect before you have to fix that; and (2) if your site is getting enough traffic to break the profile provider, it's a good problem to have.
I agree with Rex M, unless you have a need to do things like sort all your users by age or do other procedures with aggregate profile data. Then you could consider rolling your own. But for just storing properties that you access here and there on a user-by-user basis, Rex M is right.
I do know what you mean. Wouldn't it make sense to supplment the profile provider's table with another table that has columns with mandatory fields? or do you think the overhead of join would not make it not worth it?
Beside IP blocking and probably using a cookie (if the user changes the IP but doesn't remove the cookie, the new IP is added to the banned list, so the IP has to be changed and the cookie has to be removed together to access the site), is there any tricks one can use to block an annoying user from a website, I know that nothing will work with a savvy user but I'm trying to make it harder for the less savvy ones, any suggestions?
Edit: I already have registration in my website, the point is that this is useless to stop determined users (they can simply create other accounts).
#rifferte,
Actually I'm already building a moderation section where moderators can remove posts and suspend members, also members can report abuse and spam, I'm not trying to make this impossible, simply there's no way to do this, I'm just trying to get rid of the less savvy ones (the majority), and not forever, I'm planning to block them for a certain period of time (probably a couple of days or something like that).
Any overt form of censure on an existing user could lead to the forum equivalent of an arms race. One school of thought pushed on the SO podcasts is to flag the offending user and remove their posts from normal view, but include it when they (the bad user) are looking at the site. That way, they think the community is ignoring them and it makes flaming less fun. If the site isn't trying to stop them but their efforts at flaming are fruitless, they will likely just walk away.
See also this blog by Jeff
One of the best approaches I've ever encountered is the "Tachy goes to Coventry" feature in vBulletin. Adding a user to this list places them on a global ignore list that applies to everyone, except themselves.
So, they continue posting and everything appears normal from their perspective, yet their posts don't disrupt other users. Amazingly, these users rarely seem to figure out what's going on, they're so satisfied with the havoc they think they're wreaking undeterred.
Disruptive users tend to fizzle out very quickly when everyone's ignoring them. Once they give up, you can bulk delete all of their content in one pass that takes relatively little administrative effort.
What sometimes seems to help is to:
Make sure that accounts need to be "mature" before they may post.
A reputation system not unlike stack overflow (Account gone = reputation gone) :)
Use authentication providers like OpenID. It is more work to create multiple accounts that way
The simple fact of the matter is: If someone can do everything after creating an account, the account does not have any extra value. Once an account has some extra value (i.e. someone needs to put some good work in an account to get more privileges) you'll see that abusers will probably go to other websites.
I believe you will be in a constant cat and mouse game if the user has that much time to burn.
Your best bet will be to involve some human element to the site's registration process, to properly research any particular users. Not elegant, but without knowing more about your site there isn't too much more one can say.
Now that the question has been further refined with extra information, I'd like to change my answer.
Problem users in forums site exist because other users feed them.
How about trying an approach where if you identify a problem user, then you silently hide their posts from your site from OTHER users, but not the problem user. The theory is, that the problem user 'thinks' that their post made it through, but since it's actually hidden from all other users, nobody will reply to the problem user, and with any luck, they'll go elsewhere where they're getting feedback.
Can you trust your "good" user base to flag bad/annoying users?
Something like craigslist: if a user is flagged as annoying by a few users, their account is temporarily unable to post for a period of time. If this happens a few times, their account is suspended?
Just a thought.