Codeception How to test if a User has a Role - testing

I am trying to get into the habit of writing tests as I go.
I am using Laravel 4.2 to build an application that registers Users and assigns different roles to different user types.
I want to write a test that will check to see if a User has a Role. I am using Entrust to manage my Roles/Permissions and Laracasts/TestDummy to generate dummy objects.
The Roles are stored in a pivot table, so I am essentially testing for the existance of a many to many relationship
The TestDummy documentation states that I need to define my objects and their relationships in a fixtures.yml file and gives an example
Post:
title: Hello World $string
body: $text
published_at: $date
author_id:
type: Author
Author:
name: John Doe $integer
The above layout defines a one to one relationship. A post has An Author.
What I am trying to test for is A User has A Role, where many Users can have Many Roles
I want to know how to define this in my fixtures.yml file
in my mind
If I wanted to test a Many to Many Relationship (Many Users have Many Roles) could I reference it like this?
Excel\Users\User:
username: $string$integer
email: $string$integer#example.com
password: $string
created_at: $date
updated_at: $date
\Role:
name: $string
created_at: $date
updated_at: $date
Assigned_Role:
user_id:
type: Excel\Users\User
role_id:
type: \Role
The problem as I see it is that Assigned_Role does not have a model as it is just a pivot table
How could I test if a User has a specific Role?

TestDummy only supports generating belongs to relations. You can try something like this, assuming you want to test a method on User like hasRole($role).
$user = Factory::create('Excel\Users\User');
$role = Factory::create('Role');
$user->roles()->attach($role);
$this->assertTrue($user->hasRole($role));
$user->roles()->detach($role);
$this->assertFalse($user->hasRole($role));

Related

Typeorm query for entity using another entity in where clause in version 0.3.X

In my system we have users and addresses.
I want to query the addresses table for all the addresses belonging to a user.
Within the version 0.2.X I was able to write the query like
user: UserEntity = blah
AddressEntity.findOne({ user: user }))
Whereas now I need to do
user: UserEntity = blah
AddressEntity.findOneBy({ user: {id : user.id }))
Is there any workaround to support the shorthand notation again?

How to reuse swagger definitions and remove some of the parameters in it? [duplicate]

This question already has answers here:
Re-using model with different required properties
(2 answers)
Closed 3 years ago.
This is my code:
definitions:
User:
type: object
properties:
id:
type: integer
username:
type: string
first_name:
type: string
last_name:
type: string
password:
type: string
created_at:
type: string
format: date-time
updated_at:
type: string
format: date-time
required:
- username
- first_name
- last_name
- password
/api/users:
post:
description: Add a new user
operationId: store
parameters:
- name: user
description: User object
in: body
required: true
type: string
schema:
$ref: '#/definitions/User'
produces:
- application/json
responses:
"200":
description: Success
properties:
success:
type: boolean
data:
$ref: '#/definitions/User'
As you can see, in the post key under /api/users I used the User definition as my schema on it.
I want to lessen my code so I reused the User definition as my schema. The problem here is that I do not need the id, created_at and updated_at fields.
Is there a way to just inherit some of the fields except the fields mentioned? Also, I would love some suggestions to make it better since I'm trying to learn swagger. Thank you.
As explained in this answer to a similar question:
You would have to define the models separately.
However, you have options for the cases of exclusion and difference.
If you're looking to exclude, which is the easy case, create a model
of with the excluded property, say ModelA. Then define ModelB as
ModelA plus the additional property:
ModelB:
allOf:
- $ref: "#/definitions/ModelA"
- type: object
properties:
id:
type: string
If you're looking to define the difference, follow the same method
above, and exclude the id from ModelA. Then define ModelB and ModelC
as extending ModelA and add the id property to them, each with its own
restrictions. Mind you, JSON Schema can allow you to follow the
original example above for some cases to "override" a definition.
However, since it is not really overriding, and one needs to
understand the concepts of JSON Schema better to not make simple
mistakes, I'd recommend going this path for now.

KeystoneJS and naming?

I'm new to Keystone JS and NodeJS.
This is the Part I totally do not understand;
Example 'Post' as defined as 'Post', but there are no 'posts', but when I call/ search for Post, in example (and my practices), it was 'posts'.
Exp:
keystone.set('nav', {
posts: ['posts', 'post-categories'],
enquiries: 'enquiries',
users: 'users',
});
Similar 'PostCategory' => 'post-categories', 'Enquiry'=>'enquiries' etc.
But when I making new Routes=>View for my custom post type, I must use:
locals.data = {
food: []
};
At this, its 'food' not 'foods'.
Keystone automatically uses the plural form of your model names in the Admin Panel, instead of its singular name. It's still referred to by its singular name (Food, PostCategory, Enquiry, etc.) throughout your code, but the admin panel uses the plural forms if referring to multiple documents of a model.
When working with local, you can name the properties of that object anything you want. Doesn't have to be locals.data.food; it can be whatever you want.
Also, the plural form of food is food. So nothing will change when using the plural form of a Food model in your Admin Panel.

How to model restrictions on data visible on resources?

How to model restrictions on data visible on resources? Different people are accessing the same resources but with different roles so they are not allowed to see all the information.
The case I am working on:
Solution without access restriction on information:
User:
name
phoneNumber
If anyone could access it this would be easy to model as:
GET /User -> [{name:"John", phoneNumber: "322-333"}]
GET /User/{id} -> {name:"John", phoneNumber: "322-333"}
However, say I have two roles, admin and user. The phoneNumber must only be visible to users who are also admins. Authorization token is transmitted in a cookie, header or similar. The server will know which roles a requester has. How would one design an API to handle this? I have a couple of ideas:
1) The naive solution would be to just filter it and leave the fields unset if you arent allowed to access it ie.
If user: GET /User -> [{name:"John"}]
If admin: GET /User -> [{name:"John", phoneNumber: "322-333"}]
2) Embed the role in the url:
If user is wanted as a User: GET /User/User -> [{name:"John"}]
If user is wanted as an Admin: GET /Admin/User -> [{name:"John", phoneNumber: "322-333"}]
3) Define a new resource for each possible subset of fields:
If user is wanted as a User: GET /PublicUserInfo -> [{name:"John"}]
If user is wanted as an Admin: GET /FullUserInfo -> [{name:"John", phoneNumber: "322-333"}]
Would a different approach be better ?
Does anyone have experience with a solution that worked out in practice?
Use option 1 based on the authenticated user. If you opt for 2 or 3 clients implementing your API have to worry about twice as any API endpoints and when they should be used.

Database Design + Rails associations with :through using metadata

Here is the scenario: I am building a system that will let users search for each other based on their skill sets.
Users have skills. Skills are universal objects and are shared amongst users.
Users have the following metadata associated with skills: level and interest
Each user can create their own categories under which they can organize their skills (e.g. one user might have the skill "Saas" under "Front-End Development" and another under "Web Development")
I have 4 tables: Users, Skills, Categories & Skillsets
Assuming that John Doe (username: "johndoe") has the following categories and skill set:
Category: Front-End
Skills: HAML, SASS/SCSS, CoffeeScript, Javascript, jQuery
Category: Back-End
Skills: Ruby, Ruby on Rails, node.js
I'd like to be able to perform the following operations:
user = User.where(:username => "johndoe").first
user.categories
# returns a list of the user's categories
user.skills
# returns a list of the user's skills
user.category.where(name => "Front-End").first.skills
# => returns list of skills in the "Front-End" category
user.skills.where(:name => "HAML").first.category
# returns "Front-End" category
# adds a skill without assigning it to a category
user.skills << skill_object
user.skills.last.level = 9
user.skills.last.interest = 6
user.skills.last.save
# adds a skill while assigning it to a category
user.category.skills << skill_object
user.category.skills.last.level = 9
user.category.skills.last.interest = 6
user.category.skills.last.save
And in order to find users by skill:
skill = Skill.where(:name => "Javascript").first
skill.users
# returns users possessing skill
I've been playing around with my models for a while but not quite getting to behave as I'd like them to. I need a fresh perspective - Any pointers / suggestions?
I know nothing about Ruby, but from a relational db perspective, I'd probably just create a special, hardcoded, category field for each user: Uncategorized.
Then, when you add skills, they either go in a specified cateogory, or the default uncategorized one for that user. Outside of that one "special" record for each user, everything else would work perfectly no matter which skill or category you're looking at, and you can leave all your constraints in place without having to worry about null values.
UserID, User
1, me
CategoryID, UserID, Category
1,1,Uncategorized
2,1,Web GUI
SkillID, Skill
1,Javascript
2,Knitting
SkillID, CategoryID, Level, Interest
1,2,10,75
2,1,50,1
Depending on how you use Level and Interest, I'd also consider making them lookup tables to give meaning to the values from a database perspective (and help populate drop down lists).
etc.