I am developing a rails application and am using a gem called devise to manage my users. I have created a new user called "Admin" but am unsure on how to change a user on the application from a "User" to an "Admin".
On the documentation it says:
"The code below can be used to grant admin status to the current user."
current_user.update_attribute :admin, true
But where would this snippet go?
Here is the documentation, The admin role creation info is near the bottom of the page.
https://github.com/plataformatec/devise/wiki/How-To%3A-Add-an-Admin-Role
You are very close to the solution! Nothing like reading through the documentation :-)
By going with Option 2 mentioned on the wikipage, users in your application will be classified
as 'regular' or 'admin', based on the admin attribute. The wikipage gives you the code for granting admin role to the current user, and leaves the decision of where to call this code up to you.
Fair enough, since how users become Admins is specific to each application, depending on how the users want it to be done.
One way to do it would be to have a 'Grant Current User Admin Rights' action in the GUI which would invoke the code. In that case, the code would go within a 'grant_current_user_admin_rights' method in the 'users_controller.rb' file. Of course, the views and the routes should be modified accordingly as well.
You could call that code from after_create callback on the user model, ensuring all users become Admins :-)
Another way to do it would be to set the admin flag for specific users either in the console or through database seeds.
Example from a seeds file on one of my projects:
admin_user = User.new( :email => USER_EMAIL, :password => PASSWORD_STRING, :name => USER_NAME )
admin_user.admin = true
admin_user.save!
Hope this helps.
4 years late but the true answer to OPs question, when he asked where to put:
current_user.update_attribute :admin, true
can be solved by going to the terminal/command prompt.
Type in
rails c
to access the rails terminal.
then go to your user, and since you're probably the first it'll be:
user = User.find(1)
user.update_attribute(:admin, true)
Assuming you followed all the previous steps in Option 2 of the documentation, this will set your user to have a true Admin attribute.
You can verify this by going
User.find(1)
and it should say "admin: true" at the end of the big block of text.
Related
I made an app and created an authentication scheme that creates an account every time a new employee is inserted. Now I'm looking at how to set all new users as contributors. I found this PL/SQL code somewhere.
IF v('APP_USER') = 'username' THEN
apex_util.set_session_state('F_IS_ADMIN','Y');
END IF;
Now i don't know how to specifically say "all the accounts" but i came up with something:
IF v('APP_USER') IS NOT NULL THEN
apex_util.set_session_state('F_IS_CONTRIBUTOR','Y');
END IF;
I know it's probably wide of the mark as I'm having trouble understanding what 'F_IS_ADMIN' is and where it comes from but this is the best I can do at the moment (newbie). Anyone has any idea how to do this and if I went in the right direction or not?
And where do I stick this code? in the authorization scheme or in the authentication scheme?
All help and pointers very much apriciated!
First of all... what is the code you posted supposed to do ? It is setting an application item to control authorization - it doesn't have anything to do with the "Contributor" role you are talking about. Controlling authorization with application items isn't a good practice. Don't blindly copy code. Instead try to understand what it does and then implement your own version of the code you use as basis.
Now to answer your question. There are a couple of possible solutions (only one needs to be selected - pick your favorite and test first on a copy of your application):
If you insist on the user having the actual role, then you can immediately grant the role to the user when the new account is created by invoking this API.
But... if all users need the "Contributor" role - that just means that any user needs to access components that are currently protected by the "Contribution Rights" authorization scheme. Just remove that authorization scheme altogether and all those components will be unprotected.
If the option above scares you, then it's also possible to modify the "Contribution Rights" authorization scheme so it always yields true. That has the same effect as every user having the role. To do so, edit the "Contribution Rights" authorization scheme:
Scheme Type: PL/SQL Function returning Boolean
PL/SQL Function Body:
RETURN true;
A similar question was asked earlier this week: How to automatically assign USER ROLES in Oracle Apex
Creating tests in Ruby, Capybara using SitePrism. I have faced situation, where I have one site but content of the site depends on permissions the user has. For example element "admin" in menu is visible only for admins e.t.c. One major difference is that admins has their own subdomain like admin.example.com (site for normal user is example.com).
I have to test it both from admins and users point of view and I want to avoid creating two almost identical page objects.
Is there a right way to solve this?
So there are a variety of tools at your disposal here.
#all_there? will check if all declared elements are on the page. Furthermore this can be restricted down via the Use of DSL statements such as .expected_elements
I would advise you going back to the README which has a lot of new info in the last 6-9months and checking on it.
In terms of scoping so there is the concept of a user and an admin, that's also easy to partition using variables in your ENV hash perhaps and setting the url accordingly. Again there is documentation on this on the SitePrism docs/Github.
If you feel as though this still isn't working or there is an issue, open an issue request here: https://github.com/natritmeyer/site_prism/issues
class ExamplePage < SitePrism::Page
...
element :test_element, '#test_element'
...
end
...
let!(:example_page) { ExamplePage.new }
context 'situation 1' do
it 'displays test_element' do
...
expect(example_page).to have_test_element
end
end
context 'situation 2' do
it 'displays test_element' do
...
expect(example_page).to_not have_test_element
end
end
I have a User model, for login and registration, its email field is used (everything vanilla from the devise gem).
I want (other) users to be able to e.g. add Users to a team, with the email-address as the identifier.
That is fine when the User is already existing (pseudo #team.users.add(User.find_by(email: other_users_email))) but I am unsure how to handle situations where the user does not yet exist (did not [yet] register).
When a (new) User sets up a new account, for the example above after successfull registration current_user.teams should show up correctly.
I do not want to force these potentially new users to use the system (e.g. using devise_invitable) and bother them with an email.
I followed the path of creating the User when a user with the given email does not yet exist, but then when the user actually tries to setup an account, it fails (email not unique).
Alternatively, I could remodel the TeamMember-part and let it optionally either store an email-adress or the reference to an existing User. Then what I would need is to check for "open" TeamMembers directly after User-Account-creation (so, TeamMembers with the given email). I could also do this on each requst, but that looks too expensive to me. There might be race conditions, but I could live with that (and check for the every-now-in-a-millenia-gap with a cron-job).
Any pointers? I am sure this is not that unusual.
I'd do this:
When a user A adds user B to a team by email, create the object for that user B, but set a flag, something like auto_created_and_inactive: true
When user B signs up on the site, you just have to handle this in your users#create: first, try to find an auto-created record and update it (set a password or whatever; also reset the flag). Or otherwise proceed with the usual route of creating a new record.
I have to admit that I did not yet tried #sergio-tulentsevs approach (implement RegistrationController#create). But to complete what I sketched in my question:
User model can define an after_confirmation method, which is called after ... confirmation! So, if I store every information about a potential user with a reference to his/her email-adress, once he/she registered I can query this information and e.g. complete Team-Memberships.
# app/models/user.rb
def after_confirmation
# (pseudo-code, did not try)
self.teams < TeamMembership.open.where(email: self.email)
end
I've created a couple of pages they are users, groups and permissions.
I would like the admin to be able to create groups and set what those groups can do via the permissions page.
So on the permissions page I would have a list of things a user could do e.g.: add content, delete content.
And if I check the add content box then the group can only add content and not delete content.
The problem I'm having is that I don't know where to go to look for information on how to go about it. I've already got my database set up and I'm thinking maybe sessions and routes is the way to go, but I'm not sure.
Frameworks is the way to go for something this complex. I'm working on a very similar project for my work (a dashboard to do different things based on User Role/Permissions) and I found it incredibly difficult to manage without the use of a framework. I would highly recommend Cartalyst/Sentry for this. It turns complex database operations like checking permissions, update permissions, creating groups etc into simple one. Here is a link to the manual:
Cartalyst/Sentry
It has a database backend already created (and modifiable) for you, so you simply follow the installation instructions and go over the documentation to get a better understanding. In your example, it would be as simple as creating a group and it's permissions:
// Define permissions (1 is allowed, 0 is not allowed)
$permissions = array('content.create' => 1, 'content.delete' => 1, etc etc...));
$group = Sentry::createGroup(array('name' => 'Admin', 'permissions' => $permissions));
Creating a user and adding them to the group:
$user = Sentry::createUser(array('email' => 'test#test.com', 'first_name' => ..., etc));
$group = Sentry::findGroupByName('Admin');
$user->addGroup($group);
And then checking their permissions during routing:
$user = Sentry::check(); // Aka get the current user.
if($user->hasAccess('content.create'){
// Continue
} else {
// Redirect to error page, etc
}
Now that's a brief overview of the system, and I assume you know how to use controllers and routes, but play around with it and I'm sure you'll come to see how powerful this Framework is when working with Laravel.
Hope that helps!
Then checking whether or not a user
I created custom role for some users, and I assigned role to particular user with content tree limitation. Like on this image
Problem is that when that user log in, he get error like on this image. Roles are working, so user can see his assigned content tree and work with it.
How can I solved this first screen? Even redirection on his content tree would do the job.
Thank you :)
Make sure that the user you assigned the role to, also has a basic role to access basic contribution functions. I usually have a "backoffice user" role which is assigned to every contributor (or group), which includes (without any limitation) :
user/login on the admin siteaccess
content/read on at least the root node : you need to be able to get "through" that node (and others if needed) to see the ones under it
ezoe, ezjscore, ezmultiupload, ezfind, ezie etc
content/(edit|remove|...) on contents which is owned by the user himself or its group
Hope this helps