This is the user story-:
As an administrator I want to reward users for suggesting improvements to a submission so that I can increase their desire towards the system
I need to make user become senior according to their posts.
as a example
first user level is junior member then member and then senior member
Help me to figure out this!
Related
I have a question for a project I am working on. I am working on a RoR project in which a site is selling a single type of item, a book. The person I am creating this for does not want to deal with users creating user account to check out as the sales season is very short for this product, the purchases are done once per year, and the site only sells a single item.
I am wondering if there is something wrong with the implementation I am thinking of. What I was envisioning was a single database class called Orders. visitors to the site would simple fill out an order form with payment details through stripe and click submit. If they payment clears, the order with all the Orders information would be persisted to the DB. If the payment fails then it is not persisted and the relevant error information is displayed in using flash.
I suppose the meat of my question is; is there anything inherently 'wrong' about implementing this model without a users class and just having visitors to the site place orders?
I am a fairly new developer and this is my first big project so any feedback is appreciated!
If your requirements say that it is okay, then it is okay, if your requirements say it is not okay, then it is not okay.
There's not more to say, since only you know what your requirements are.
I have a comprehensive web platform where I have roles such as applicant, member, administrator (financial, technical, etc.). A member is a role that a web site applicant purchases a login account. During the lifecycle of this platform, a member is can be disabled for various reasons.
If a member wants to become active, he or she must have certain access, depending on the reason for their inactivity, for example, to pay for their annual subscription money or complete their qualifications.
The question is how can I restrict a disabled member from accessing certain functions. As we know, one of the easiest and safest ways is to use role attributes on top of the action
[Authorize (Roles = "member")]
Assuming we have two reasons for deactivation, is it right to temporarily change the role of the member to one of those two reasons and given that the user no longer has the role of member?
Solution Two: Is it the right thing to check in each of our important functions each time that the member is active?
Or another way ...
Thanks for guiding me.
Respectfully
My web app will have users fill out an application for their profile. Users can enter their skills with years of experience on them. I might have a skills table in my database. A User has_many Skills and a Skill has_many Users.
When a skill has many users, wouldn't that make my table extremely huge because although a skill may already be created in the db, it would have to create a new row to match the user_id? If so, is there a more efficient way to do this (I imagine this format would be costly for the server)? Generally speaking, users could have a range of 0 skills up to 100's each.
The skills need to be cross referenced with a posting so that only users who meet x skills can see y posting. For example, the posting requires that user has x, y, z skills with the correlating lengths of experience. This would be a set of control structures. Say one user puts his skill is 'rails framework' and another user puts his skill is in 'rails development'. These are the same skills, but for the person making the post, to make sure they're getting all qualified users, they have to enter each format of the skill. Is there a way around this so it is more effective and efficient?
It might have a LinkedIn, StackOverflow, Quora styled format for skills where they start typing a skill and it autocompletes/creates suggestions and then the user just clicks the appropriate skill.
For the first part of your question, what you're looking for is either a has_and_belongs_to_many or has_many :through association:
http://guides.rubyonrails.org/association_basics.html#the-has-and-belongs-to-many-association
http://guides.rubyonrails.org/association_basics.html#the-has-many-through-association
Essentially, you have a table of users, a table of skills, and a third table which serves to join particular users with particular skills.
The 2nd part of your question is a complicated one. By allowing users free reign over entering the skills into your system you lose some control. This is something StackOverflow also has to deal with. Here it is addressed with moderators and community edits, which earn the individuals helping out credits within SO.
Depending on the sort of system you're building, you'll either need paid moderators to provide tight control over how everything is working, or open it up to the community so that they can get it to work the way they want it to. Both of these have their pros and cons, but without keeping complete control over the skills list you can't get away from the issue of duplicate or very similar skills which ought to be the same thing.
Reading online material (e.g. Fowler, Gerard), it seems that Specification By Example stories should not be complete specifications of functionality.
Question 1: How does one starting off with SBE's decide how comprehensive their stories need to be in terms of describing all of the functionality of a system? I.e. when can I stop writing stories because I have captured enough?
Question 2: In an organisation where test teams verify products against the product documentation, if the stores are not a complete specification, am I correct in thinking that 'other' product documentation needs to contain all the cases that are not covered by the SBE's?
Regarding question 1:
The most important part of developing any system is that the development team has a conversation with the product owner. First find out the crux of the feature which they require. I'll answer this question by working through an example; let us say that the product owner may want a facility to login to their new website. This requirement could be written as:
In order to gain access to the website's facilities
As a user
I want to be able to login to the website
(Note that I'm using the Gherkin domain specific language for writing the scenarios and features in this answer)
With the product owner's key requirement specified, you should now discuss with them how you think this feature should be implemeneted from a users perspective (keep it high-level, don't use technical jargon, discuss with the business to find out what they want). So the first "happy path" scenario you might identify could be:
Given a user is on the login screen
When they submit valid login credentials
Then they gain access to the main website
After further discussion with the product owner they tell you that as the website contains extremely sensitive information, and that any failed log-in attempts should be reported to a system administrator. This would result in another scenario:
Given a user is on the login screen
When they submit invalid login credentials
Then the system administrator is informed of the failed log-in attempt
And the user is informed that their login attempt failed
At this point the product owner might say that these are the only scenarios they want for logging into the system. So from the development teams perspective no more investigation would need to be done regarding this feature (so you wouldn't need to write any more user stories). Sure, at a later point in the projects development, the product owner might also tell you that they'd like to inform a user when they last logged into their site before reaching the main website, but you'd only need to worry about this when they ask for it.
Regarding question 2:
The organisation should be verifying the products against "living" documentation e.g. using Cucumber(for example) which generates tests from the scenarios detailed above.
Also as I said in the answer to question 1, you should identify "just enough" of the scenarios/use cases to satisfy the product owner. What the product owner asks for is the complete specification. Don't try and second guess what the product owner might want because this may result in be a classic case of YAGNI.
Using Rails and am new to it (and RDBMs). Have read lots of posts and articles on modeling and associations, but could really use a reality check on what I'm thinking for my particular case.
I have 3 main models: users, accounts, plans. The accounts are multi-user, with plans worked on by all users attached to the account (with varying privileges). If the account is destroyed I’ll also take down its users and plans.
Looks like the basic associations would be as follows. Is this correct?
users
belongs to - >
< - has many
accounts
has many ->
<- belongs to
plans
Is there any value in associating users with plans with “has many through”? I see that it would allow access like #user.plans and #plan.user[1], but can’t I access each via accounts, as in #user.account.plan?
Is it the case that with “has many through” the middle model simply belongs to the other two? All the examples I’ve seen show that. In my case, that would be inappropriate, since account actually owns the other two.
Is there a better way to model this (multiple users of an organization working on a set of one or more plans)?
Input is very much appreciated.
Your design is correct. The belongs_to terminology can indeed be a bit strange, but is proper. Use "has many through" if it makes your code more readable and obvious. (In other words, if the notion of a user having a plan makes sense, and is needed, go ahead and create the relationship. If it is more clear to conceive of the plan belonging to an account, then stick with user.account.plans.)
Your design should be sufficient so long as you don't need to restrict a user to a subsets of the plans belonging to an account, and so long as a user only belongs to a single account.