I need advice if my approach is right
I would like to create a digital checklist for several test types with the possibility that users can add further questions to the checklist at any time.
I have four models for this. Questions, Checkpoints, CheckTypes and Checks
Question
Users should be able to create questions. Each question has such a check type (name:string checktyp_id:integer) Example Name: "Is enough oil in the tank", checktyp_id:1
Check type
There are basically three types of testing (small, medium and large) Example Name: "Small Check"
Checkpoint
each probe has the following values passed (io:boolean) failed (nio:booelean) OK after repair(inst_io:boolean) the examiner (user_id:integer) test date(check_date:date)
Example: Check_id:integer, Question_id:integer, io:boolean, nio:booelean, inst_io:boolean, user_id:integer, check_date:date
Checks
This is the main form. If the action new is called there, the CheckTyp_id should also be selected.
The behavior of the form:
The Check new action is called with the parameter checktyp_id:1. Now all questions with this checktyp_id should be available in the form. Each question should then have the choices (io, nio, inst_io...) in the form.
The model connections:
Question
->belongs_to check type
Check type
-> Has_many questions
Checkpoint
-> Belongs_to question
-> Belongs_to check
Check
-> has_many questions trough checktyp_id
-> has_many checkpoints
-> belongs_to check type
Is this correct, or am I thinking too complex?
Related
User story: User can create a Template. Each template has_many questions. User has_many templates. Template and Question belongs_to user.
Right now the user can create questions for a template. User clicks on template and they see a list of questions.
Problem:
How do i turn this into a form where the user can answer the questions. The user needs to be able to use the template and infinite amount of times. A user must be able to click what template they want to use then fill out the form.
Thank you for any assistance.
Although your question is a bit vague, it sounds like you need to set up a couple tables to hold answers to your questions, which also belong to a user. I would recommend a table to hold a reference to all responses for a given template: i.e. belongs_to :user, :template. Then, create a table to hold answers to each question, maybe called answers? Each row would belong to a user and question and thus a given 'template' with a through: option set on a has_many association. Does that make sense?
I have a Ruby on Rails app where there are Sales Opportunities. Each opportunity is graded by the User according to where they believe it belongs in the sales pipeline. This is set up as an enum currently on the Sales Opportunity model, and the user just selects the appropriate stage from a dropdown list. The stages are "Prospecting", "Qualifying", "Demonstrating", "Negotiating", "Closed Won", "Closed Lost" and "Dormant".
I am now looking to build more sophisticated features for a premium part of the product - specifically I want to be able to add questions to the Sales Opportunity that the user answers - e.g. "Does the prospect have a budget?", if yes: "How much is their budget?" etc.
Depending upon the answers to these questions I want to display a result to the user telling them where in the sales pipeline this opportunity should belong, rather than where it currently is.
I was thinking of adding a qualifying_questions class relationship to Sales_Opportunity.rb:
class SalesOpportunity < ActiveRecord::Base
belongs_to :user
enum pipeline_status: [ :prospect, :qualifying, :demonstrating, :negotiating, :closed_won, :closed_lost, :dormant ]
has_many :qualifying_questions
end
and then creating QualifyingQuestions class:
class QualifyingQuestions < ActiveRecord::Base
belongs_to :sales_opportunity
end
But this is where I'm getting stuck in my mind. Each question is likely to have different characteristics - e.g. in my example above the first questions's answer is a boolean (do they have budget?) whereas the next (assuming the answer was yes) is either a fixnum ($20,000 for example) or a selector saying "unknown", or if they don't have a budget (answer no to the first question) I want to ask "is there a process to allocate budget?" etc.
I could create a class for each individual question I ask, and set the data types accordingly - but this seems to be massively bloating the code, and it means my questions need to be hard-coded into the app. Ideally in future I'd like to allow my Users to define their own questions for each stage in the sales process, so I should try and design it to be flexible for the future.
I'm sure there's a straightforward way for me to achieve this, but I'm not sufficiently experienced to know it yet. Can anyone help point me in the right direction please?
I have one type of user creating form fields for a job posting. They can define the field type and name (eg. type:"string" and name:"job_title").
My question is how do I store this data so that the job form for the applicant user has all of these defined fields?
Currently the job and form template is organized like this:
job BELONGS TO employer_template
employer_template HAS MANY jobs
employer_template HAS MANY template_fields
I've tried to search for solutions, but haven't seen anything that answers it clearly enough.
I would avoid to create all those tables, it sounds an overengineered solution.
You could simply serialize the fields and the contents, and store them in just one field.
That is automatically done by serialize:
class employer < ActiveRecord::Base
serialize :custom_fields
end
Simple and fast :)
I have an app that is dealing with "patients". Each patient is going to have three forms that they deal with initially. Each form has related questions, but they also have differences, so they can't be the same form. Each answer, even if it is for the same question, has to be recorded and archived. Also, there needs to be some sense of versioning to each form that is filled out. For instance if patient "Steve" fills out "Form 1" on "October 5th", and a question is taken away from the form the next day, I need to still be able to pull up the questions that Steve filled out on Form 1. Right now I have four models that I think solve this problem which are:
patients: first_name, last_name
forms: name, version
form_response: patient_id, form_id
questions: content, form_id
answers: response, question_id, form_response_id
Would this be the best way to map out this data set? Also, should this all be handled through the patient model? If not, what type of model structure should be used to handle this? I'm just really confused on how to best handle this situation as far as what should go where and not end up with a mess of code to maintain. Thank you in advance for your help.
You have the right ides. Starting from the top:
form
has_many questions
questions
belong_to form
has_many answers
answers
belong_to question
belong_to response
Then you tie it together with the response:
response
belongs_to patient
belongs_to form
I would suggest looking into form objects to make this a lot easier. You might want to checkout:
Form-backing objects for fun and profit
Rails Form Objects
Form Objects
I have a User model in my app, which I would like to store basic user information, such as email address, first and last name, phone number, etc.
I also have many different types of users in my system, including sales agents, clients, guests, etc.
I would like to be able to use the same User model as a base for all the others, so that I don't have to include all the fields for all the related roles in one model, and can delegate as necessary (cutting down on duplicate database fields as well as providing easy mobility from changing one user of one type to another).
So, what I'd like is this:
User
-- first name
-- last name
-- email
--> is a "client", so
---- client field 1
---- client field 2
---- client field 3
User
-- first name
-- last name
-- email
--> is a "sales agent", so
---- sales agent field 1
---- sales agent field 2
---- sales agent field 3
and so on...
In addition, when a new user signs up, I want that new user to automatically be assigned the role of "client" (I'm talking about database fields here, not authorization, though I hope to eventually include this logic in my user authorization as well). I have a multi-step signup wizard I'm trying to build with wizardly. The first step is easy, since I'm simply calling the fields included in the base User model (such as first_name and email), but the second step is trickier since it should be calling in fields from the associated model (like--per my example above--the model client with fields client_field_1 or client_field_2, as if those fields were part of User).
Does that make sense? Let me know if that wasn't clear at all, and I'll try to explain it in a different way.
Can anyone help me with this? How would I do this?
STI is probably a good fit for your requirements, as suggested by tadman, if you are using ActiveRecord (from Rails 3, it is easy to change ORM). The basic information is available on the AR documentation page, but here is some extra information w.r.t. your target:
Define one model per file. Otherwise there are some initialization troubles. Assuming Client inherits from User all in a single file, Client objects cannot be created as long as a User constructor has not been called once. One file per model circumvents the problem.
All attributes through the hierarchy are defined one-shot in the top class. This is for performance issues, but it seems disturbing many people in blog posts. In short, the Ruby code is object-oriented and encapsulates properly the attributes. The DB contains everything in a single table, with the extra "type" column to distinguish where they belong in the hierarchy. This is only a "trick" to represent inheritance trees in relational databases. We must be aware that the ORM mapping is not straightforward. The image on this site from Martin Fowler may help understand the situation.
In addition, you would like any new user to be a client, where Client inherits from User. To do so, you may simply instantiate any new user as a client. In your controller for creating users:
user = Client.new
# Do something to user
user.save
#=> <Client id: 1, name: "Michael Bolton", email: "mike#bolton.net", created_at: "2010-05-30 03:27:39", updated_at: "2010-05-30 03:27:39">
All the above is still valid with Rails 3 when using ActiveRecords.
It looks like you have two reasonable approaches here, but it will depend on the nuances of your requirements.
You can use Single Table Inheritance (STI) to do what you want, where User is only the base class for others named SalesAgent or Client and so forth. Each of these sub-classes may define their own validations. All you need for this to work is a string column called "type" and ActiveRecord will do the rest:
class User < ActiveRecord::Base
end
class Agent < User
end
The alternative is to have a number of free-form fields where you store various bits of related data and simply interpret them differently at run-time. You may structure it like this:
class User < ActiveRecord::Base
has_one :agent_role,
:dependent => :destroy
end
class AgentRole < ActiveRecord::Base
belongs_to :user
# Represents the agent-specific role fields
end
That would have the advantage of allowing for multiple roles, and if you use has_many, then multiple roles of the same type.