Models

Below are the models of the core app.

CustomUser

Model to record user information. Django provides a User model for this, but for recommendation, further manipulation and customization, a separate model is created that inherits the properties of the AbstractUser class.

  • email: To register user’s email address.

  • is_business: Boolean field to indicate if the user is of business type.

  • password: Stores the password of the hashed user (from AbstractUser).

  • first_name: Stores the first name of the user (from AbstractUser).

  • last_name: Stores the last name of the user (from AbstractUser).

  • is_staff: Boolean field to indicate that the user is the django-admin system super user (from AbstractUser).

  • is_active: Boolean field to indicate if the user is active or not (from AbstractUser).

  • date_joined: Records the date of the last login to the system (from AbstractUser).

It’s methods are:

  • create_user: Method to create a new user. Validates if a user with the same email exists, if so, it triggers a ValueError type exception. If it doesn’t exist, create it. It does not require to instantiate the model.

  • create_business_user: Method to create a new business type user. Validates if a user with the same email exists, if so, it triggers a ValueError type exception. If it doesn’t exist, create it. It does not require to instantiate the model.

UserProfile

Model for recording user profile information.

  • user: To register user’s email address.

  • photo: Stores the password of the hashed user (from AbstractUser).

  • job_title: Stores the first name of the user (from AbstractUser).

  • language: Stores the last name of the user (from AbstractUser).

  • country: Boolean field to indicate that the user is the django-admin system super user (from AbstractUser).

  • date_format: Boolean field to indicate if the user is active or not (from AbstractUser).

It’s methods are:

  • get_photo: Method to create a new user. Validates if a user with the same email exists, if so, it triggers a ValueError type exception. If it doesn’t exist, create it. It does not require to instantiate the model.

NotificationType

Choice model that stores the notification types of the Notifications model.

The fields are:

  • TYPE: A tuple of the notification types.

It’s methods are:

  • get_available_type_notifications: Transforms the TYPE tuple into an object for further manipulation.

Notifications

Model to record general system notifications. It relies on the NotificationType choice model to determine the type of notification stored.

The fields are:

  • uuid: To register user’s email address.

  • message: Notification message.

  • url_link: If the notification requires a redirect link, it is stored here.

  • text_link: Text that is placed in the redirect link (url_link).

  • other_tab_link: Boolean field to indicate if the link should be opened in another tab or not.

  • type_notifications: Notification type. This field is a choice associated with the NotificationType model.

  • active: Boolean field to activate/deactivate the notification.

  • language: To indicate which is the language of the notification. This links to the language set by the user in the UserProfile model.

It’s methods are:

  • short_message: Method that returns the first 35 characters of the notification message.

  • create_notification: Method to register a new notification. It does not require to instantiate the model.

GlobalSettings

Model to set global system configurations. Naturally many of the application’s configurations are done through settings variables. However, when making a change in any variable, the system must be deployed again. To make the configuration of certain modules and actions more dynamic, this model was implemented.

The fields are:

  • name_app: To set the name of the app. By default the name of the app is Easystart, however, if there is a data stored in this field, this will be the one that will be displayed.

  • logo_app: NStores the path where the application logo image file is registered. The path is the one returned by the global_settings_logo_directory_path function.

  • session_expire_time: Field that records the duration of inactivity in the user session. If this field is empty or there is no GlobalSettings record, the value of the settings variable SESSION_EXPIRE_TIME is taken.

  • active_audit: Boolean field to enable/disable the audit module.

  • active_ip_authorization: Boolean field to enable/disable the new device and ip authorization module.

  • active_registration: Boolean field to enable/disable user registration from the frontend. This can disable the register_view of the accounts module.

  • active_captcha: Boolean field to enable/disable the Captcha module.

  • header_scripts: Text field to store scripts that want to be inserted in the application’s html header.

  • footer_scripts: Text field to store scripts that you want to be inserted just before closing the body tag of the application’s html.

  • body_scripts: Text field to store scripts that you want to be inserted right after the body tag of the application’s html.

  • active_email_provider: Boolean field to enable/disable sending email via an email provider.

It’s methods are:

  • get_logo: This method provides the logo of the application in base64. In the event that it has not registered any, it returns the path of the logo by default.

IpAuthorization

Model to momentarily store the information of a new device, IP address and user. In addition to the code that is sent to the user’s email address to later validate it.

The fields are:

  • user: Relationship to the CustomUser model

  • ip: Records the unregistered ip address for that user.

  • device: Stores the new unregistered device for that user.

  • code: The code for the validation of the new device or IP is registered.

  • sent: Record the date the email was sent with the verification code.

It’s methods are:

  • get_or_create: Returns an instance of the model. If there is a record for that user with the device and ip, the instance is returned. Otherwise a new record is created and that instance is returned. No need to instantiate the model

  • verify_code: Method that verifies the validity of a code sent to check the device and ip. It does not require to instantiate the model.

  • code_expired: Check if the code has expired. You need to instantiate the model.

  • time_to_resend_email: Returns the remaining time to be able to resend the email with the verification code.

  • can_send_cooldown_period: Method that returns a boolean indicating whether the email can be resent with the verification code, depending on the creation time. It does not require to be instantiated.

  • delete_ip_auth: Method to remove a record from the model.

WhiteListIpAuthorization

This model registers the devices and IP authorized by the user. The fields are:

  • user: Relationship to the CustomUser model

  • ip: Records the unregistered ip address for that user.

  • device: Stores the new unregistered device for that user.

It’s methods are:

  • verify_user_ip: Checks if the device and ip pair associated with a user is registered in the model. It does not require to instantiate the model.

  • register_user_ip: Registra un nuevo par dispositivo e ip asociado a un usuario. No requiere instanciar el modelo.

EmailProvider

Model that records the information necessary for integration with an email delivery provider.

The fields are:

  • PROVIDERS: Tuple with the providers integrated in the system.

  • provider: String that registers the provider. Only allows values ​​from the PROVIDERS tuple.

  • from_email: Email address from which emails are sent.

  • name: Friendly name for the provider.

  • secret_key: Stores the secret key provided by the provider.

  • active: Boolean field to activate or deactivate the provider.

It’s methods are:

  • get_available_providers: Method that transforms the tuple into an object. It does not require to instantiate the model.

  • create_provider: Method to save a provider. In this model, the default templates are created in the EmailProviderTemplate model. It does not require to instantiate the model.

EmailProviderTemplate

Model that records the identification information of the email delivery templates associated with the provider.

The fields are:

  • provider: Relation to the EmailProvider model.

  • name: Identification name of the template in the application.

  • template_id: Template identification id associated with the provider.

  • language: Language in which the text of the email will appear.

  • can_delete: Boolean field to determine if a template can be deleted or not.

It’s methods are:

  • create_default_template: Method to create the default templates of the application. These are set with the can_delete field in False and blank in template_id (This is so because at first this data is not known).

  • create_template: Method to create new email templates. Unlike the previous method, these can be deleted (can_delete = True) and the template_id is recorded.