As a freelancer, I used opencart for my clients, one table called users, another table called customers.
I tried wordpress + woocommerce, that's only one user system. I haven't really used this, just test.
If we use only one user system, I have a question. What/how account should the employee/staff use? Use the private email, like peter#gmail.com? This maybe not easy to manage. Any characters could be the email. like haha123#gmail.com. then we don't know who is who.
Or create a company's account like peter#nike.com, force the staff to use the real name.
But when a staff have two accounts, he login as staff at work time. And he buys things for himself. Then he resigned, leave the company. His work email is canceled, frozen, inactivated. Which means that he cannot access his own order records. And maybe the private order is still ongoing, haven't received, not paid yet. This caused problems.
What solution should we use?
WordPress is based on the Roles and Capabilities system. Users will have a role while Each role will have different capabilities assigned.
Whenever WordPress code performs an action as a logged-in user, it basically checks if the user has the capabilities to perform that action or not.
As you explained in your use case, in that case, a staff member will be assigned a role(let's call it manager) that will allow them to do some staff-related things and he can also use that account to make orders and buy things.
If he resigns then the site manager/admin will change his role as a customer and will allow him to use the website and buy things but he won't be able to staff related things, because the custom role will not have those capabilities.
And in some cases, his connection with any data that should be only assigned to staff will be removed and assigned to someone else.
In short, capabilities do all the magic here and instead of assigning multiple capabilities to each user, WordPress creates a role with a set of capabilities to make it simple, and we can assign that role to a user and change it anytime, to revoke or grant more capabilities.
Related
Since I had problem with Passport multi auth, I wonder is it necessary to have an admin guard (and an admins table) or it's better to use the default guard (and users table) for both admins and users with the help of role and permissions? Which is better?
That's a really hard question to answer without more information, but I'll try looking at it from a few perspectives:
You have an application that has users that can turn into admins (and vice-versa)
In this situation, I would probably have a single table that contains an is_admin column and use the column to validate whether the user can perform administration tasks (e.g. by using Laravel's gates). The downside to this is that if you wanted to create a third type of user (e.g. supervisor), you would need to change the model used.
You have an application where users are completely separate from administrators
If you control the administrators and everyone else is just a user, creating separate guards could be used, this does allow for a lot of flexibility in the future if you wanted to implement different authentication flows for both administrators and users (for example, using SAML). If you were to add a third type of user (e.g. supervisor), you could then just create another guard.
You have an application that can have different (customisable) permissions for each user
In this case I would recommend implementing a roles table, a permissions table, a role_permissions table and adding a column called role_id to the user table. This provides the most flexibility and is also usable with the Laravel's gate system, but is probably the most difficult to setup and hardest to maintain.
For the application I develop, we use a mixture of roles and guards. We use roles for users as each user gets a customisable set of permissions. We then use a separate guard for API users which inherit the permissions of the user they were authenticated with.
I’m new to google classroom api. I want to create a process that will query all classes, students, assignments etc. It will run unattended.
So, my questions are:
will offline scope allow the process to query the api unattended?
can only an admin user see all classes, students, assignments?
or, can a g-suite user be created with limited read-only permissions to certain resources?
Thanks
Since this is an unattended batch process and Google OAuth access tokens expire after 1 hour, you will likely need offline access. You can do this by adding the parameter access_type=offline in the authorization URL.
In terms of actually acquiring all classes, students, assignments, etc., here are a few things to note:
If you're a domain administrator, you can retrieve courses, students, assignments, invitations, etc. in their domain and will not need each teacher to authorize these requests.
If you don't have domain administrator access and want to retrieve all these items, you will have to have each teacher authorize your request(s).
As for your last question, I'm not entirely sure what you mean -- could you clarify? Are you asking is if one workaround would be to create a G Suite user that has read access to all these resources and then use that account to make all the requests?
You can create a service account and use it to query all data on behalf of users-
https://developers.google.com/identity/protocols/OAuth2ServiceAccount#delegatingauthority
I am designing a website for tech events, which needs to have both an admin display and a public / user display. Admins of course can manage events, users etc. Users can save events, register, share events. E.g in the public / user navigation I have tickets, reminders, etc.
Now I can´t decide if all the users features has to be present in the admin display as well, or only the admin / managing features? What is best practice and why?
In our university system, the admin can take over the role of any student.
This is to identify problems and / or help users not used to the system.
Also, when a new feature is added to the system, it helps a lot in terms of debugging and testing.
I think the biggest plus for this practise is to take the role of a user and see why a certain feature might not work correct, or where the said user has problems working with the system. This, of course, requires the users to trust the admins.
We are trying to integrate our platform with Pipedrive. As far as we have researched, in a pipedrive account, there is one admin and he can add multiple users. And the users later can login in their respective accounts.
What we are trying to make sure is that once a Pipedrive account is integrated with our platform, the same account should not be integrated twice. So, I need a unique identifier, that lets me know whether the account has already been integrated.
My initial approach was to check the api key. But it was not successful, since every users in an account have different API Keys.
After a bit of research, I found out that there is an identifier called company_id which is common for all the users in an account. But I could not find anything regarding it in documentation. So, I am not 100% confident to go ahead and implement it in our code.
Does anyone have an idea about this?
Pipedrive support rep here.
The most sure-fire way to ensure this is to make a GET request against http://api.pipedrive.com/v1/users?api_token=your_token_here.
You are correct in assuming the company_id in the additional_data object in the response is static and won't change across any users on the account.
Note that a Pipedrive account may have more than one admin, and that non-admins (regular users) might have visibility (and editing) restrictions in place, which may cause some of your GET, PUT and DELETE requests to fail.
In case you're not doing this already, I'd thus advise filtering the data array from the abovementioned endpoint for user.is_you to equal true and check whether the is_admin property is set to 1 during "registration" to ensure the user setting up the integration is an admin.
Hope this helps!
I'm not quite sure what you're asking for. Are you looking for a unique identifier for each user?
Each user has an id, you can get all users by calling
https://api.pipedrive.com/v1/users?api_token=____
This will return a JSON Object with data on your users, including their names and associated IDs. Admins are just users with different privilege levels. All admins are users, but not all users are admins. All users are part of a company, the company is identified by the first part of the Pipedrive account url ie.
https://FooCompany.pipedrive.com
Are you trying to see if a certain company has been integrated already?
I am about to define permissions for users in my project. I checked the laracasts videos regarding ACL, Roles and Permissions.
I have a doubt. Do I need Roles for normal users?
I mean, in my project a user should be able to create / update / delete his own posts, he should be able to comment on his own posts and posts by other users and delete his posts and posts left by others on his own posts.
The point is: do I really need to define Roles for this kind of permissions? Shouldn't I just define some policies like can / can't post / update / delete etc. and only define roles for admins?
You don't necessarily need a full featured, powerful Roles/ACL system but if you are storing both admin and basic users in the same table then you do need something to distinguish between them. This could be something as simple as a Role field as a string on your users table e.g. Admin or Basic, or even a boolean is_admin field.
This would give you the ability to implement a Policy or Middleware to prevent basic users accessing the admin panel, and you can have permission checks to ensure a user can't update other users posts etc.
If you don't foresee needing anything more complex in future then this would suffice. However, as your app becomes more mature, you might wish to have a more advanced roles system, for example where a user needs to have multiple roles.
You don't necessarily need to define a role for every user...
It's probably a good idea to, however, you can 'hardcode' and make some assumptions about some of the access...
For example:
If you assume that anyone who is logged in can make a post and can edit their own post, you don't need to make a role for users to say "can_make_post", just have a check saying "if user is logged in, then let them make a post"
then if you say, have an admin area, then you can go "if user a has role
with the 'admin_access' permission, then allow access"
It would be a good idea to have roles for everything, as it allows more customisation, however, your the one designing it, if you don't need the customisation, you can probably just make some assumptions like above.