I am quite new to ACL
The website is about cars where a dealer can have several brands and in several countries.
For example:
Dealer: John Doe
has the brands Audi in UK, and Kia in France.
I have the below models:
- Brand
- Country
- Dealer
- BrandsCountriesDealers (which links the above three together)
The dealer cannot add / edit a brand or a country. He can only add/edit/delete a car in the country that he has access to and to the brand that he owns.
I was wondering if I use a specific foreign key of the BrandsCountriesDealers model as an ACO only and when the dealer adds a car, I check if this car's brand and country are valid by checking the record in the BrandsCountriesDealers model which he has access to ?
I hope this was clear.
Implementing ACL is a bit hard but not impossible. Once you get use to working with ACL you undrestand how easy and powerful it is. It might take some research to configure and learn it but it is really worthed.
I think you should use ACL for certain reasons:
It makes your code very clean and tidy:
You don't need to keep assign
if user logged in do this
or if user type is this do that
Access Level: No need to write validation for each types of user.
High Security: ACL is working with Auth component
each method can be granted to one or more user type (Role)
Almost every thing is stored in DB so your code is clear again
I remember when I started to work with ACL I followed this tutorial. It is in Portuguese language. I don't know this language but I followed step by step and get it worked.
http://www.youtube.com/watch?v=EIjfwqqGRhs
Related
I am currently working in a sales tracking project - where I am constantly getting into situation where I have to duplicate code about listing, showing or editing models.
I have 3 models, Lead, Customer, and Sales Activity. with 1:1 relations between Lead and Customer and 1:M relation between Lead and Sales Activity.
What I want is that when I SHOW a Lead, I should be able to reuse the show function of customer admin class, and I don't have to redo it in the show function of the Lead admin class.
Similarly, I want to be able add the LIST and CREATE function of the Sales Activity class into the Lead SHOW function without having to recode that which is already present. I could use render(controller()) in a custom template - but that includes the base template as well of the target controller, and it just messes the whole layout
I appreciate any input on the matter. thanks for your time.
Basic answer would be Admin class inheritance.
Another one would be to make a trait with your configureShowFields and use this trait in all of your admin classes.
If you are open to trying out a new bundle you can check : https://github.com/blast-project/CoreBundle
This bundle allows configuration of you admins in Yaml
And one of the features would suit your use case it would look like:
all:
Sonata\AdminBundle\Show\ShowMapper:
add:
name:
type: text
address:
type: textarea
...
It will let you configure your mappers for all your admins
I'm trying to understand the best approach to extract key content during a conversation. I'll use a simple travel interaction example:
I've created a conversation that supports travel activities, and after greeting the user they are asked how can I be of help?
The user responds: I have a flight to Las Vegas today and I need to make a change to my reservation.
Defining the proper Intents and Entities we conclude they want to change a reservation. I want to understand how can I identify, and extract from the response key words like "Las Vegas" and "Today"?
Is there an approach using Watson APIs or do I need to write custom code to dissect the response based on the matching Intents and Entities?
As an example I'd like to confirm to the user: I understand you have a flight to Las Vegas today and would like to make changes to that reservation. Is that right?
Appreciate any advice you can share.
It sounds like you need a place/destination/airport entity, for places like Las Vegas, and an entity for days. You can then use conditions in your dialog flow based on which entity value was matched, for example #place:(Las Vegas). Or you can just repeat the matched entity back to the user in the response, for example I understand you have a flight to #place.
Have a look at the Dialog reference documentation for more information on using entities.
Also, if it helps, there are some examples of day entities in the conversation-starter project entities.csv file on GitHub, and I'm tempted to add an entity for airport codes there if I get a chance.
I'm not sure whether this is best done using Views or Rules - I'm no expert on either.
The node is a quiz and I want the quiz creator to be able to restrict access to their quiz so it's only available to those users the quiz creator have previously flagged - i.e. if I follow you, you can access my quizzes.
So far...
I've created a View to display only quiz nodes and created a relationship to the content:author. If I then create a relationship to bring in flag info, the available options only seem to deal with content the author has flagged not the users.
How do I bring the logged in user into the equation in order to filter the nodes by their flag status?
Or am I not on the right track trying to do it with views?
I'm building a site for a summer camp using Drupal 7, and I'd like for it to allow parents to register their kid(s) for week(s) at camp and then pay for it.
Creating an "event" for purchase in Ubercart, and using the pay per node module is the best way i can find to make this happen, a la the great tutorial series done by Pete Yaworski. Unfortunately, this means that parents have to fill out the fields for each week of camp purchased for each kid making this a multi-step process as many parents have 2 or more kids that they register for 2 or more weeks of camp.
I tried thinking about this in in terms of the Organic Groups and Profile 2 modules, where parents can create "kids" as nodes or sub-users, and I also tried the Field Attributes module to incorporate fields as product options, but I failed to come up with any useful implementation.
I think the best option is to allow Parents enter information about their kids (ie. name, age), possibly by entering each kid as a node. Ultimately, I'd like them to be able to purchase individual camp weeks and check a checkbox to indicate which kids are associated with each week, and have it all go into one cart for one purchase.
I'm just brainstorming at this point because I've just hit upon a lot of dead ends. Thanks for your help!
Well, it's been a while and i thought i might share what i've learned. Just to note, i switched to Drupal Commerce, which i think is much better equipped to handle this type of business.
The site is more focused on one user registering multiple people (kids) for multiple events, so having to fill out a registration form for each person specifically for each event that person is being registered for is a bit annoying, and bad UX. Instead, i allow registered users to complete a form (name, address, contact, etc..). Upon completion of the form, they are given a new user role via Rules which allow them to create content of type "kid". This is really sort of an extra step for the specific summer camp site; we expect the kids to have the same address/phone/etc.. as their parents. The parents can create "kid" nodes filling in field like "allergies" "health concerns" "age" and "name". These nodes are passed through a View with a Contextual Filter based on the User viewing the View; the View shows only content created by the User, and only shows field "name". This is then given as an entity reference to a Line Item Type using a checkbox/radio widget. Events can then be created as Products and given that Line Item Type. When a User is viewing the products he/she will see the "Name"s of the "Kids" they have created as choice next to the "add to cart" button. Conveniently, everything in Drupal Commerce from Products to Orders can be interpreted though views, so as long as the "kid" is attached as a line item, it's easy to organize the info about who registered who for what event when, and retrieve further details about all of that.
So, Parents are able to register with the site, fill out basic information, enter in information for each kid they want to register, then select which kid they want to register for which event. More useful, on the backend, the admin can see which kids are registered for which event, as well as who their parents are, how to contact them, and any important info specific to that kid.
Hope this helps anyone doing a similar project. :-)
I would like to ask you guys if you could review my database design. I think it is quite self-explanatory, but to be absolutely clear:
My goal is to make an application which has a super flexible user management (which is why the groups are in tree-form and the groups and users have a habtm relationship) and a super modular way to build pages (which is why the pages consist of widget-blocks).
The reason I made users and profiles separate is because the users table will not change and is only needed for authentication and authorization. However, the profiles table will change according to the wishes of the client. So it might not have a signature, but an avatar field instead. Or maybe it will be completely empty / not exist at all.
A widget could be anything, it could be a poll, it could be a piece of content, it could be a navigation, it could be a collection of comments, whatever.
The reason I chose to make subdomains, locales and layouts separate tables instead of just putting the names into pages is because I want to limit the options that are available to the client. Just because I have a three-columns.ctp in my layouts folder doesn't necessarily mean I want the client to be able to choose it.
Same goes for the widgets. And besides limiting choice, not every plugin, controller and action in my plugins-folder is a widget, so I need a table to clarify which are.
A block is a widget on a page which sits in a container (e.g. the right column in a 3 column layout) at a particular position which is decided by the index (lower index means higher).
So that's my explanation, what do you guys think? Is this as good as it can be? Or do you have (a) suggestion(s) to make it even more flexible and modular.
[edit] Oh and to be clear, the widgets will of course have their own tables to store the information they need to store.
Well, I think that everything is great except "profiles".
When you try to get data from a logged user:
$this->Auth->user();
I don't think that you will get data about "profiles" so you will have to find profile by $this->Auth->user('id') etc. I think that you should merge "profiles" and "users" tables into "users" table.
So when you want to save, let's say, "signature" you should just put it in $this->request->data; and call $this->User->save($this->request->data); and the signature will be updated.
EDIT:
You can leave it the way it is but, to get other data than user, you will have to put:
$id = $this->Auth->user('id');
$current_user = $this->User->findById($id);