Ahoy Gem - Logging account_id for visits and events along with user_id - ahoy

In our application, users belong to an account. Each user has a user_id and account_id. We would like for the account_id to be logged as a column in ahoy_visits and ahoy_events, just like user_id, to make it faster and easier to retrieve usage data for a specific account. Our solution to this currently is to monkey patch the methods for authentication, visits, and users. However, this feels a little dirty. Is there a better approach?

Related

How to Implement multiple kinds of users in Django?

I am new to Django so please bear with me if my questions seem too basic.
So, I want to create a web app for a kind of a store in which I have three different kinds of users.
Admin(Not Superuser) who can:
create, view, update, delete account for a Seller(agent)
issue them inventory
Seller who can:
sell an inventory item to a Customer(customers cannot themselves purchase it, only the seller can do it by filling in a form)
a Customer account should automatically be created upon submission of the form by Seller or if the Customer already has an account, the purchase should be added to their account
Customer
can login and view their account
What would be the best way to go about it? Using auth Groups, Profile models or anything else?
Any help would be wonderful. If something is not very clear in the question, I can provide more details. Thanks.
Django already has a solution for this: a Group [Django-doc]. A user can belong to zero, one or more groups. A group can have zero, one or more Permissions [Django-doc].
These permissions can be defined by a Django model, for example for all models there are permissions, to view, add, change, and delete objects of a certain model, but you can define custom permissions as well, for example to visit a certain page. A user then has such permission if there is at least one group they are a member of that has such permission.
You can work for example with the #permission_required decorator [Django-doc], or the PermissionRequiredMixin [Django-doc] to enforce that only users that have the required permission(s) can see the given page.
You thus can make groups for a seller, customer, etc. Often people can have multiple roles, for exame being both a seller and a customer which thus is elegantly solved through the permission framework.

Extend wagtail page visibility and add subscription plans

I'm creating a website with wagtail where users can decide to buy a subscription plan.
Each subscription should allow access to a page on the site. For example, "only users in the premium plan can read the news."
The subscription must have an "expiry date".
At the moment the visibility can be blocked to users in a specific group (which can be managed as a subscription) but I don't know how to manage the expiration date and it doesn't seem to be a particularly elegant solution for my problem.
I haven't found anything to create a custom model user_group with an expiry_date field.
I would like to know how a situation like this should usually be handled and if it is possible to add another entry in the visibility section, for example: "private, accessible to users in specific subscriptions".
Create your own middleware to check whether the subscription has expired and then remove the user from the group if the subscription is expired: https://docs.djangoproject.com/en/3.0/topics/http/middleware/#writing-your-own-middleware

Many-to-many relationship between Django User, Permissions, and another entity

Consider a Django web app for CompanyXYZ that provides goods and services to many organizations. Users of the app will be affiliated with one or more of those organizations, and have different roles (and be permitted access to different data) within each. So, imagine a schema like this:
Users>---UserOrg----<Org
V
|
UserOrgPermissions
|
^
Permissions
Permissions relate to services provided by the company, and in general look like: “Can order X”, “Can view X orders”, “Can order Y”, “Can view Y orders”, “Can order Z”...etc. Users should be able to log on to CompanyXYZ’s site once, and then choose from among his/her affiliated organizations to view summary data and/or place orders, depending on his/her permissions at a given organization.
From an admin perspective, I need to be able to create organizations, create users, assign users to organizations, and assign permissions to users for each of his/her organizations.
I’m fairly new to Django, so I'm not sure if this is even doable. How would I start?
That would be something like this:
class Permission(models.Model):
pass
class Org(models.Model):
pass
class UserOrg(models.Model):
org = models.Foreignkey('Org')
user = models.Foreignkey('User')
permissions = models.ManyToManyField(Permission)
class User(models.Model):
orgs = models.ManyToManyField(Org, through=UserOrg)
I suggest you to either read the docs or start with their tutorial for beginners.
Django provides you almost all for you needs. Try to learn about users first. Avoid to create users from scrach, you can simple use or customize the Django User models. then, permissions and organizations can be solved with groups.

Rolling out own permission app or modifying django permission

I am working on a project which needs a separate admin interface. The django admin interface is for the super super user, there will be companies who will sign up for our app and then they will have their own admin interface. Everything is set and done despite the permission. We want model level permission that's what Django provides.
What I did is:
class CompanyGroup(models.Model):
name = models.CharField(max_length=254)
permissions = models.ManyToManyField(Permissions)
Now this list all the permissions of the site itself. So, Should I start working on my own permission app or I can modify django Permissions to provide object level permissions for only some models.
Thanks
Try one of the several existing 'row level' / 'per object' permissions apps for Django:
http://django-guardian.readthedocs.org/en/v1.2/
http://django-object-permissions.readthedocs.org/en/latest/
...there are probably others, those are just the first two in Google
We are using django-guardian in current project at work, seems fine.
I am assuming that you need to control access to sub-sets of each model's objects, depending on which company the current user belongs to (i.e. you don't want people from Company A to see items from Company B). For this reason you need row level permissions.
You probably also need to limit the permissions of all 'company users' to only certain actions:
You do not need to create a CompanyGroup class.
Instead just enable the admin site, log in as super user and create a django.contrib.auth.models.Group which contains the global permissions applicable to company users.
then ensure when you create any new company user logins that they are added to that Group

Django 1.5 employee-management where some employees can login some can't

So I want to keep track of about 100 employees but only five of them should be able to log in into the backend (the rest starts with no loginpossibilities at all) what's the best way to solve that problem ?
I thought of an EmployeeModel that has a 1to1-relation to an abstractBaseUser but is that the way to go or is there something easier ?
~Max
Why not make use of Django 1.5's new customisable User model and model each employee as a user with an extended profile:
In Django 1.5, you can now use your own model as the store for user-related data. If your project needs a username with more than 30 characters, or if you want to store user’s names in a format other than first name/last name, or you want to put custom profile information onto your User object, you can now do so.
By making each employee a "user", you have the balance of being able to control their ability to login (using is_staff) as well as being able to add as much employee profile information that you need.
Why not just have FK from employee to user if an employee has an attached account?
Don't go for over customisation as this can be easily achieved easily using the built-in tools. Make the login_page require a permission suppose say "can login". And just make these 5 users have those permission. So rest will automatically get a permission denied response when trying to login.