New to MVC and RoR and having a hard time grasping some of the concepts. One of them is batch updates to the database.
Lets say I have a set of data such as a list of students and their attributes like this
Student ID:1
Name: Alice
email:alice#alice.com
attribute: anything
attribute2: anything2
Student ID:2
Name: Kate
email:kate#kate.com
attribute: anything
attribute2: anything2
etc..
I've gotten the list from an API call.
I don't want them to be editable, nor do I want the attributes to be visible to the user.
Question is, how do I go about saving them into my database? It seems in the MVC way, each action requires a view? Will I be able to do it as a background process?
Thanks
Ryan
p/s- pointers to the right resources welcome too
So you'd just like to obtain records from an API and create models from them?
One option you may consider is writing rake tasks to get the data, and create the corresponding models (No rails answer is complete without a railscast link, so here's one It's old, but tells the basics)
Going this route, you could avoid making the data publicly editable, and just get it into the models/DB
You could use fixtures for this type of thing. Or, just use SQL to insert into your DB outside of Rails.
http://api.rubyonrails.org/classes/ActiveRecord/Fixtures.html
Related
App Attributes:
Rails 3.2, Mongoid, Devise, Elasticsearch
Basic Structure:
User has a Post
Post can be seen by other users
Situation:
A User wants to remove the post from being view-able by other users for a period of time.
Note
Eventually I would like to extend this capability so that its possible for said user to be able to make it only viewable to certain colleagues. This way they can collaborate on the post together.
Problem:
I can't seem to think of a good way in rails to do this. One idea I had was to create a Boolean field in the post model that would allow me to achieve some of this but the ACL's would tricky and unstable at best. So I'm reaching out to the great intelligence this should be cake for some of you.
The solution you suggest is the one that occurs to me. Place a boolean flag private on the Post model, and modify the code you use to fetch Posts to exclude ones with the flag set unless they belong to the current user, (depending on whether private posts are viewable by their owner in that particular context).
I haven't actually worked with Mongoid, but I believe this is as simple as Post.any_of({private: false}, {user_id: current_user.id})
If and when you implement the collaboration functionality you discuss, all you need to do is change that code again - fetch posts that are not private, or that belong to any one of a given set of users.
Theoretical question. Lets say I build an application for managing clients, products, bills and such. All without a user login.
Is it possible to get multi user (each one with his own clients,products,...) functionality after the main application is done?
Or should I think of the multi user in the first place? How flexible is rails at this part?
thanks in advance
dennym
What you are asking for is a pattern called Multitenant. There are different ways to do it, but none are provided by Rails natively.
You could start with this slide: http://www.slideshare.net/tardate/multitenancy-with-rails
And figure out if you want to do; partitioning based on data, Rbac, model or schema.
There are is one that offers it as a service that says that it is easy to do after you have your application: http://railskits.com/saas/
But in our experience, it was a bit outdated and missing some features that we wanted.
You can also take a look at other gems like: multitenant or act_as_tenant.
We ended up using act_as_tenant and doing it from the beginning.
So I need more alongs the lines of just advice than actual code here, but this is my situation:
I have a model that requires two associations - an author and a user. However, I want it to be possible for authors to create the record with the possibility that it will later be "claimed" by a user created later.
The best solution that I've come up with is to user some sort of "Dummy User" association for those cases, but it feels hacky.
Any better suggestions?
How about making the associations not required? Are the associations enforced with validations? How about relaxing the validations instead? So there would be no user association persisted until the time it is claimed.
I'm using devise for authentication and I'm looking for an authorization framework that lets me declare edit permissions for specific model attributes.
I have three different roles in my app: Teacher, Parent, and Student. The Student model belongs_to Family. When a Teacher creates a Student, they are able to set the Family association. When a Parent visits the edit page for a Student, however, they should not be able to change that association, only view it.
In the view, it's easy to alter the form depending on who is viewing it (disable or don't disable the family select input, for example) but a crafted form can get around that. What I need is something that will throw some kind of authorization exception when someone tries to change an attribute that they are not allowed to change.
I'm currently looking at declarative_authorization, but it seems it's not fine-grained enough to restrict changes to attributes, only the model as a whole.
I've ended up using the new MassAssignmentSecurity feature, although it looks like it might not work that great in conjunction with accepts_nested_attributes_for.
I realize my answer comes 2 years late. For what it's worth what you need is an authorization framework that is fine-grained enough.
XACML, the standard from OASIS provides just that. It can handle any number of attributes.
See my detailed answer here: Rails 4 authorization gem
I have two models, we'll call them Entry and Comments for our example, that are associated as Entry has_many :comments and Comment belongs_to Entry. When a new comment is created, I need to obviously supply the id of the Entry for the foreign key. Right now, I'm using a query string. It works like this. A user views and entry, clicks a link to create a new comment (the link looks something like b/new?a_id=1) and then I use the build method to create the new record.
I know if I nested the resources it'd work just fine, but there are reasons that I don't want to do that, namely that I plan to nest a resource under Comments and don't want to go so many levels deep.
I initially had the form for a new comment on the Entry show page, but was having problems doing some custom validations and passing the error messages, etc. (namely, I needed to count the words before submitting).
Any thoughts? I'm not opposed to using query strings, just not sure if there's a better way.
I honestly can't see the problem with nested resources. You're going to have to identify the Entry in your case so your choices are POST /entries/123/comments or POST /comments?entry_id=123. Personally I prefer the former.