DEV Community: Antonov Mike

TypeScript warnings

Antonov Mike — Fri, 03 Apr 2026 13:07:04 +0000

I really don't like the way JavaScript / TypeScript works with unused variables.

I guess unused variables, constants and imports should be underlined by default.

I mean by default, so you don't have to configure it manually:

package.json

{
  "type": "module",
  "devDependencies": {
    "@types/node": "^25.5.2",
    "@typescript-eslint/eslint-plugin": "^8.58.0",
    "@typescript-eslint/parser": "^8.58.0"
  }
}

eslint.config.js

export default [
  {
    files: ["**/*.ts"],
    languageOptions: { ecmaVersion: 2021, sourceType: "module" },
    rules: {
      "no-unused-vars": [
        "warn",
        { vars: "all", args: "after-used", ignoreRestSiblings: true },
      ],
    },
  },
];

{Updated on 2026.04.04}

Rules for frontend (React TypeScript)

eslint.config.js

import js from "@eslint/js";
import globals from "globals";
import reactHooks from "eslint-plugin-react-hooks";
import reactRefresh from "eslint-plugin-react-refresh";
import tseslint from "typescript-eslint";
import { defineConfig, globalIgnores } from "eslint/config";

export default defineConfig([
  globalIgnores(["dist"]),
  {
    files: ["**/*.{ts,tsx}"],
    extends: [
      js.configs.recommended,
      tseslint.configs.recommended,
      reactHooks.configs.flat.recommended,
      reactRefresh.configs.vite,
    ],
    languageOptions: {
      ecmaVersion: 2020,
      globals: globals.browser,
    },
    rules: {

      // Disable the TS version (if it sets an error)

      "@typescript-eslint/no-unused-vars": "off",

      // Enable the base rule as a warning.

      "no-unused-vars": [
        "warn",
        { vars: "all", args: "after-used", ignoreRestSiblings: true },
      ],
      "prefer-const": ["warn"],
    },
  },
]);

Event Loop: Call Stack, Web API, Task Queue, Microtask Queue

Antonov Mike — Sun, 30 Nov 2025 08:10:11 +0000

JavaScript runs synchronously. The Event Loop enables efficient management of asynchronous operations, providing non-blocking code execution. Understanding how the Event Loop, the call stack, the task queue, and the microtask queue work helps developers write more efficient and responsive web applications.

The Event Loop is a mechanism in JavaScript that allows asynchronous processing of events and tasks, ensuring non-blocking code execution. This is especially important for web applications, where the user interface must remain responsive even when long-running operations are performed.

Main components of the Event Loop:

Call Stack: This is a data structure that keeps information about the currently executing function calls. When a function is called, it is pushed onto the stack, and when it finishes execution, it is popped off the stack. If the call stack becomes empty, it means all synchronous tasks have completed.
Web APIs: These are a set of built-in functions and methods provided by the browser or the JavaScript runtime environment (e.g., Node.js). Examples include setTimeout, setInterval, fetch, DOM events, etc. When an asynchronous operation is invoked, it is handed off to the corresponding Web API, which performs the operation and places the result into the task queue.
Task Queue: This is a queue where tasks that are ready to run are placed. When an asynchronous operation completes, its callback is added to the task queue. Tasks in the task queue are executed in order when the call stack is empty.
Microtask Queue: This is a separate queue for microtasks such as Promise callbacks and MutationObserver. Microtasks have higher priority compared to tasks in the task queue and are executed before them. ### Example of the Event Loop in action

console.log('-> 1');
setTimeout(() => console.log('----> 2'));
Promise.resolve().then(() => console.log('---> 3'));
console.log('--> 4');

Step-by-step explanation:

Synchronous operations: console.log('-> 1') runs and is processed on the call stack. setTimeout() is handed to a Web API and control returns immediately. Promise.resolve().then is scheduled in the microtask queue. console.log('--> 4') runs and is processed on the call stack.
Microtask Queue: When the call stack is empty, the Event Loop checks the microtask queue. Promise.resolve().then runs (pushed to the call stack), then console.log('---> 3') executes.
Task Queue: After all microtasks have finished, the Event Loop checks the task queue. The setTimeout() callback is placed in the task queue. console.log('----> 2') runs. ### Execution result:

-> 1
--> 4
---> 3
----> 2

Conclusion:

Understanding the Event Loop and its related components—the call stack, Web APIs, the task queue, and the microtask queue—is essential for building responsive and efficient JavaScript applications. The Event Loop provides non-blocking execution: synchronous operations run first, microtasks (Promise, MutationObserver) are handled immediately after, and then macrotasks (setTimeout, I/O, etc.) run afterward. Knowing the priorities and execution order allows you to predict asynchronous behavior, avoid race conditions and UI blocking, and write more stable and performant code.

Makhabat Abdisattarova Как работает Event Loop в JavaScript? Микрозадачи, Очереди задач и Web API | JavaScript

Odoo General settings: Technical

Antonov Mike — Thu, 27 Jun 2024 13:07:35 +0000

~ $ cat disclaimer.txt
It so happened that I needed to understand
the Odoo interface, so I decided to keep a
brief description of the Technical menu. M
aybe it will make it easier for someone to
learn Odoo. Please note that this text may
contain errors and inaccuracies.

The following is a listing of the Technical menu sections and a brief description of each subsection

Discuss

The "Discuss" section is designed to customize the discussion functionality within Odoo. Here you can configure modules for different types of content, such as forums, chats, etc., as well as manage user access to these features.

Sub-menus:

Messages. This is the main section for sending and managing messages within the system. Users can send messages to each other as well as reply to them. Messages can be attached to different objects in the system, such as tasks, projects or partners.
Scheduled Messages. Allows you to schedule messages to be sent in the future. This is useful for automatically sending notifications or reminders of upcoming events.
Subtypes. Message subtypes allow you to categorize and filter messages into different categories. For example, you can have subtypes for task notifications, questions, and suggestions.
Tracking Values. Used to track changes in discussions and posts. This can be useful for tracking the history of changes or for analyzing trends in discussions.
Activity Types. Activity types define the different types of actions that can be performed within a discussion. This can include reading a message, marking a message, deleting a message, and so on.
Activities. Activities display the current actions to be performed in the discussion. This can be useful for team coordination or for tracking the progress of tasks.
Notifications. Notifications allows you to automatically notify discussion participants of new messages or changes.
Followers. Allows you to specify users who follow the discussion but are not active participants. They receive notifications of new posts.
Email Blacklist. Allows you to block sending/receiving messages to specific email addresses.
Ratings. Allow discussants to rate posts or ideas.
User Settings. Allow you to individually configure the user's behavior and preferences in discussions, for example, the level of notifications or visibility of messages. Here you can also add employees or partners of the company to the user list.
Guests. Guests allow discussion participants who do not have an account in the system to interact with discussions. This can be useful for temporary participants or for open discussions.
RTC Sessions. Allow users to share video and voice calls within Odoo Discuss. You can start a video or voice call and customize settings such as disabling microphone, camera and screen sharing. During an RTC session, you can share the screen with other participants.
ICE Servers (Interactive Connectivity Establishment). These servers help establish direct connections between devices without the need to use proxy servers. ICE Servers settings in Odoo are typically provided in the form of URLs or IP addresses of STUN and TURN servers, which are used to break through NAT (Network Address Translation) and enable communication on restricted networks. This is especially useful for the video conferencing and instant messaging functionality provided within the Discuss module.
Message Reactions. Manage and view the reactions left by users to messages.
Link Previews. Settings for displaying link previews in posts and discussions.

Email

The Email section contains settings related to email. This includes configuring how to send emails via SMTP, creating email templates and managing email newsletters.

Sub-menus:

Emails. In this section, you can view and manage all emails sent and received.
Outgoing Mail Servers. Here you can configure and add settings for outgoing mail servers that are used to send emails from the Odoo system.
Incoming Mail Servers. Allows you to configure the settings of incoming mail servers used to receive emails to the Odoo system.
Email Templates. In this section you can create, edit and manage email templates that can be used to automatically generate messages from the system.
Aliases. Manage email address aliases that can be used for email forwarding in Odoo.
Channels. Ability to configure and manage communication channels within Odoo that can be used for communication and notifications.
Channels/Partner. Managing partner-related channels within the Odoo system.
Mail Gateway Allowed. Manage the settings of allowed mail gateways that can be used to exchange e-mail messages.
Snailmail Letters. The ability to manage and track emails sent through a regular postal service (e.g. printed letters).
Digest Emails. Setting up and managing digest mailings that can be automatically generated and sent to system users.
Digest Tips. Manage the content and settings of tips that can be included in email digests.

Phone / SMS

Allows you to set up integration with communication systems to automatically send SMS or calls in response to certain actions in the system.

Sub-menus:

SMS. This section allows you to send SMS messages directly from Odoo. You can select the contacts or groups of contacts you want to send a message to and write the text of the message. After sending a message, you can track its delivery status.
MS Templates. SMS templates allow you to create standard messages that can be reused. This is especially useful for sending similar types of notifications, such as booking confirmations, discount notifications, appointment reminders.
Phone Blacklist. Phone Blacklist allows you to block SMS or calls from being sent to specific phone numbers.

Mass Mailing

This is a section for tracking and analyzing the execution of bulk mailings in Odoo, which allows you to manage and optimize the process of communication with customers or users.

Sub-menus:

Mailing Traces. Allows you to view information about mass mailings that have been sent from the Odoo system. In "Mailing Traces" you can see the following data: Status (e.g. sent, queued, failed, etc.); Sent on Sent on (datetime); Failure type.

Actions

From here, you can set up various automatic actions that will be performed in response to certain events in the system, such as automatically assigning tasks or sending notifications.

Sub-menus:

Actions. In this section, you can create and manage various activities in the Odoo system, such as creating records, performing actions on records (e.g. changing status), sending notifications, etc. Actions can be associated with different events or triggers in the system.
Reports. Allows you to set up and manage reports in the Odoo system. This includes creating new reports, setting up report templates, setting up filters and data groupings for reports, and more.
Window Actions. Here you can configure the actions related to opening forms and windows in the Odoo user interface. For example, you can configure actions when a record form is opened or when a user performs a specific action.
Server Actions. Allow you to create actions that are performed on the server side of the Odoo system. These activities can include performing calculations, sending notifications, automating processes, and more.
Configuration Wizards. In this section, you can create configuration wizards that help users configure various system settings and features.
User-defined Defaults. Allow you to define user-defined default values for various fields and parameters in the Odoo system.

IAP

Set up in-app purchases, allowing users to purchase additional services or items directly within the app.

Sub-menus:

IAP Account. Here you can create and edit accounts for various IAP service providers such as Google Play Store, Apple App Store, and other platforms. This includes setting up API keys, product IDs, and other parameters required for integration with IAP platforms.

User Interface

This section allows you to customize the user interface, including themes, languages, and other visual presentation controls.

Sub-menus:

Menu Items. Here you can customize application and module menus by adding, removing or moving menu items. This allows you to organize the navigation of the system in a way that is more convenient for a particular user.
Views. In this section, you can customize "Views" for different data models in the system. "Views" determine how data is displayed in the user interface, including forms, lists, and charts. You can create your own "Views" or customize existing "Views" to better fit the needs of your organization.
Customized Views. This section allows you to create and save custom "Views" that can then be applied to different data models. This is useful if you want to quickly switch between different sets of view settings without having to re-configure them each time.
User-defined Filters. Here you can create and save user-defined filters to quickly search and filter data in the system. This can greatly simplify working with large amounts of information, allowing users to focus only on the data they need.
Tours. These are a series of steps that show new users the basic functions and capabilities of the system. By creating tours, you can customize the learning process for a new user, showing them how to use key features and how to achieve specific goals.

Database Structure

From here, you can configure the structure of the database, including data models, fields, and relationships between them. This is important for developers working on extensions or modifications to existing functionality.

Sub-menus:

Decimal Accuracy. In this section, you can adjust the precision for decimal numbers in the Odoo system, which affects formatting and calculations.
Assets. Allows you to manage resources (e.g. CSS, JavaScript) in the Odoo system that are used for the look and functionality of the user interface.
Models. Here you can view and manage the data model definitions in the Odoo system. Models are a structure of data that is used to store information (e.g., products, customers).
Fields. Allows you to view and manage field definitions in data models. Fields define the types of data and characteristics that can be stored in records.
Fields Selection. Control which fields are available to select when creating reports or other custom UIs.
Model Constraints. Here you can define constraints for data models that enforce data integrity and validation rules when retaining records.
ManyToMany Relations. Manage ManyToMany relationships between data models, allowing you to link records between different models.
Attachments. Allows you to view and manage attachments (files) associated with various records in Odoo system.
Logging. Manage and configure logging of system events and activities to track and analyze user and system performance.
Profiling. Ability to profile and analyze the performance of queries and operations in the Odoo system database.

Automation

Automation allows you to set up rules and processes that will be automatically triggered in response to certain events in the system.

Sub-menus:

Scheduled Actions. This section allows you to create and configure automatic actions that will be executed on a schedule. Examples of such actions include sending notifications, running data processing, running reports, and other automated tasks.
Scheduled Actions Triggers. In this section, you can configure conditions and triggers for triggering scheduled actions. Triggers define under what conditions or events a scheduled action should be executed. Button "New" calls form (ir.cron.trigger) with 2 fields: "Cron" of type Many2one and "Call At" of type datetime.

Reporting

Reporting provides tools for creating and customizing reports that can be used to analyze data in the system.

Sub-menus:

Paper Format. This section allows you to customize the paper format for printing reports. You can select sheet size, orientation, Left/Right Margins, and other settings that affect the appearance of the report when printed.
Reports. In the Reports section, you can create, customize, and manage reports in the system. Reports in Odoo can be based on data from any model and can include various types of analysis such as summary tables, charts, graphs, etc. You can customize reports for output in a variety of formats including PDF, XLSX and HTML, making it easy to distribute analysis results to different users and environments.

Sequences & Identifiers

Used to generate unique numbers for records in the system, such as orders, sales, or projects.

Sub-menus:

External Identifiers. This section allows you to manage unique identifiers that are used to reference objects and records in the Odoo system. External identifiers facilitate integration and interoperability with other systems by providing stable references to objects in the database.
Sequences. Here you can create and manage sequences of numbers that are used to generate unique numeric values in the Odoo system. Sequences are widely used to automatically generate unique numbers for documents, orders and other records.

Parameters

Settings allow you to configure various global system settings that affect system performance.

Sub-menus:

System Parameters. Here you can configure the settings that affect the operation of the entire system as a whole. These settings can include security settings, localization, time and date settings, and other global settings that determine the behavior of the system. For example, you can set the time zone that will be used in the system or configure the language of the interface.
Company Properties. In the "Company Properties" section, you can configure company properties that affect how data is displayed and processed in the system for a given company. This may include setting up currency, tax rates, company address, and other company information. These settings help ensure that the data is displayed correctly and complies with the legal requirements for a particular country or region.

Security

Security provides configuration of access rights and user roles, as well as data security management.

Sub-menus:

Record Rules. This section allows you to configure rules that determine user access to specific records in the database. For example, you can create a rule that allows or prohibits a user from viewing, creating, modifying, or deleting certain records in data models. (Create, read, unlink, delete)
Access Rights. From here, you can manage shared permissions for data models and their fields. Permissions define what actions users can perform on objects and data in the Odoo system. (Read, Write, Create, Delete)

Privacy

Settings of the privacy policy and the processing of personal data in accordance with the law.

Sub-menus:

Privacy Logs. This section allows you to keep records of data privacy activities in the Odoo system. Privacy logs record operations such as data access requests, updates to sensitive information, and other events related to the processing of users' personal data. These logs can be very useful for auditing and compliance with data protection legislation. They help organizations prove that they monitor the processing of their users' personal data and take steps to protect that information.

Resource

Management of company resources such as equipment, materials, etc.

Sub-menus:

Working Times. Here you can customize working times for employees, including working hours, overtime, and days off. This allows you to accurately track how much time each employee spends at work and helps with task planning and resource allocation
Resource Time Off. This section allows you to manage employee vacation days. This includes assigning vacations, keeping track of time spent on vacation, and managing vacation requests.
Resources. Here you can manage the resources that can be brought in to perform tasks. Resources can include human, material, equipment and other assets.

Calendar

Tools for scheduling and tracking events and tasks.

Sub-menus:

Meeting Types. This section allows you to configure and manage meeting types in Odoo, such as Interview, Meeting, Calls, Product Demos, etc.
Calendar Alarm. In this section, you can set up notifications and reminders related to calendar events in the Odoo system. For example, you can set reminders for upcoming appointments or events so that users don't miss important meetings.

Composition in Rust and Python

Antonov Mike — Sun, 12 May 2024 10:09:26 +0000

Disclaimer

This is more my attempt to explain this topic to myself. How successful it is is for more experienced people to judge. Argumented criticism in an acceptable form is welcome as always

Introduction

Composition in programming is a way of building complex structures by combining simple structures. Rust and Python both support composition, which means you can combine the features of different classes or traits to create more complex and powerful classes or types. This approach promotes code reusability and modularity. Let's explore how composition can be used in both languages to model a car rental system.

Rust Example

In Rust, we can use traits and structs to model different aspects of a car rental system. For example, we might have a Car trait, a Rental struct, and a Customer struct.

trait Car {
    fn get_make(&self) -> &str;
    fn get_model(&self) -> &str;
}

struct Rental {
    car: Box<dyn Car>,
    customer: String,
    rental_days: u32,
}

struct Customer {
    name: String,
    rentals: Vec<Rental>,
}

struct Sedan {
    make: String,
    model: String,
}

impl Car for Sedan {
    fn get_make(&self) -> &str {
        &self.make
    }

    fn get_model(&self) -> &str {
        &self.model
    }
}

fn main() {
    let sedan = Sedan {
        make: "Citroën".to_string(),
        model: "C3".to_string(),
    };

    let rental = Rental {
        car: Box::new(sedan),
        customer: "John Doe".to_string(),
        rental_days: 7,
    };

    let customer = Customer {
        name: "John Doe".to_string(),
        rentals: vec![rental],
    };

    println!("Customer {} rented a {} {} for {} days.",
             customer.name,
             customer.rentals[1].car.get_make(),
             customer.rentals[1].car.get_model(),
             customer.rentals[1].rental_days);
}

Output:

$ cargo run
Customer Kurmanjan Datka rented a Citroën C3 for 7 days.

In this Rust example, we define a Car trait that any car type must implement. We then create a Rental struct that contains a boxed Car trait object, allowing for any type that implements Car to be rented. This demonstrates composition by combining different traits and structs to create a more complex system.

Python Example

In Python, we can achieve a similar effect using classes and inheritance. Python's dynamic typing makes it easy to compose objects from different classes.

from typing import List

# Here we declare classes to use them as types
# later to make our code more readable
class Customer:
    pass

class Rental:
    pass

class Car:
    def __init__(self, make: str, model: str):
        self.make = make
        self.model = model

    def get_make(self) -> str:
        return self.make

    def get_model(self) -> str:
        return self.model


class Rental:
    def __init__(self, car: Car, customer: Customer, rental_days: int):
        self.car = car
        self.customer = customer
        self.rental_days = rental_days


class Customer:
    def __init__(self, name: str):
        self.name = name
        self.rentals: List[Rental] = []

    def add_rental(self, rental: Rental):
        self.rentals.append(rental)


class Sedan(Car):
    pass


sedan = Sedan("Citroën", "C3")
customer = Customer("Rita Levi-Montalcini")
rental = Rental(sedan, customer, 7)
customer.add_rental(rental)

print(
    f"Customer {customer.name} rented a {customer.rentals[0].car.get_make()} {
        customer.rentals[0].car.get_model()} for {customer.rentals[0].rental_days} days."
)

Output:

$ python main.py 
Customer Rita Levi-Montalcini rented a Citroën C3 for 7 days.

In the Python example, we define a Car class with methods to get the make and model. We then create a Rental class that takes a Car instance, a customer name, and the number of rental days. The Customer class contains a list of rentals. By using inheritance (e.g., Sedan inherits from Car), we can easily compose different types of cars and rentals.

Both examples demonstrate how composition can be used to build complex systems by combining simpler, reusable components.

So what are the differences?

The difference in composition between Rust and Python lies in how they organize and utilize objects and data structures, as well as in memory management and type mechanisms. While Python supports inheritance, allowing classes to inherit from other classes, Rust does not support inheritance in the same way. Instead, Rust encourages composition through traits and struct composition. This leads to a more modular and flexible design, where components can be combined in various ways to achieve the desired functionality. Python's inheritance model can lead to more tightly coupled designs, whereas Rust's composition model promotes more decoupled and reusable components. Both options have their pros and cons depending on where you use them.
In summary, while both languages support principles of composition, they do so differently, taking into account their unique features in type typing, memory management, and software architecture.

These articles may be useful

Writing Python like it's Rust
Inheritance and Composition: A Python OOP Guide
[Python App: Rental Car Cost Estimator
](https://www.youtube.com/watch?v=LcsEf9IdATA)
design-patterns/strategy
Rust takes the composition over inheritance approach
Design patterns strategy

Image created by Bing and edited by me

Encapsulation in Rust and Python

Antonov Mike — Fri, 05 Apr 2024 10:00:48 +0000

Disclaimer

I am sure that there are inaccuracies, and maybe even mistakes in this text. I am always happy to receive objective criticism in an acceptable form.

Introduction

Encapsulation is a fundamental concept in object-oriented programming that allows for the bundling of data with the methods that operate on that data. Rust and Python both support encapsulation, which means you can control the access to the attributes and methods of a class or a trait using public, private, and protected modifiers. This concept is implemented in different ways in Rust and Python due to languages design and paradigms. In Rust, we use pub to make methods and structs accessible outside their module because default they are private. In Python, we use double underscores __ to public by default attributes and methods private. Both languages provide mechanisms to control access to the data, ensuring encapsulation.

Encapsulation in Rust

In Rust, encapsulation is achieved through the use of struct and impl blocks. A struct is used to define a data type with named fields, and an impl block is used to define methods associated with the struct. In Rust, encapsulation is achieved through the use of pub and pub(crate) (protected) modifiers. Here's a simple example:
src/employee.rs

// Define a struct with field (it is private by default)
pub struct Account {
    // Private fields
    balance: f64,
}

impl Account {
    // Public method to create a new Account
    pub fn new(initial_balance: f64) -> Account {
        Account {
            balance: initial_balance,
        }
    }

    // Public method to get the balance
    pub fn get_balance(&self) -> f64 {
        self.balance
    }

    // Public method to deposit money
    pub fn deposit(&mut self, amount: f64) {
        self.balance += amount;
    }

    // Private method to apply fees
    fn apply_fees(&mut self) {
        const FEE: f64 = 2.5;
        self.balance -= FEE;
    }
}

src/main.rs

mod employee;
use employee::Account;

fn main() {
    let mut account = Account::new(100.0);
    account.deposit(50.0);
    println!("Balance: {}", account.get_balance());
    // This line will not compile because apply_fees is private
    account.apply_fees();
}

Attempting to call the apply_fees method will result in an error:

error[E0624]: method `apply_fees` is private
  --> src/main.rs:9:13
   |
9  |     account.apply_fees();
   |             ^^^^^^^^^^ private method
   |
  ::: src/employee.rs:26:5
   |
26 |     fn apply_fees(&mut self) {
   |     ------------------------ private method defined here

In this Rust example:

In the Rust example, we have a simple Account struct with a private field called balance. Here’s how it works:

Struct Definition: We define the pub struct Account in the src/employee.rs file. The balance field is private by default (not exposed outside the module).
Public Methods: We provide public methods new, get_balance, deposit. These methods allow controlled access to the balance field.
Private Method: The apply_fees method is marked as private (not accessible outside the struct). It deducts a fixed fee from the account balance.
Usage in main.rs: In the main function, we create an Account instance, deposit money, and print the balance. Attempting to call apply_fees results in a compilation error since it’s private.

Python Example

Python uses a different approach to encapsulation, primarily through the use of underscores to denote private attributes and methods. However, it's important to note that Python's privacy is more of a convention than a strict enforcement. In Python, all attributes and methods are public by default. To make an attribute or method private, you prefix its name with double underscores (__). This does not make the attribute or method truly private, but it signals to other developers that it is intended for internal use within the class. The provided Python example demonstrates encapsulation by defining a class with a private attribute (__balance) and public methods (__init__, get_balance, deposit). The __apply_fees method is intended to be private, but due to Python's lack of strict access control, it can still be accessed from outside the class, although it is not recommended.

# Define a class with private attributes
class Account:
    def __init__(self, initial_balance):
        self.__balance = initial_balance  # Private attribute

    def get_balance(self):
        return self.__balance

    def deposit(self, amount):
        self.__balance += amount

    def __apply_fees(self):  # Private method
        FEE = 2.5
        self.__balance -= FEE

# Create an instance of Account
account = Account(100)
account.deposit(50)
print("Balance:", account.get_balance())
# This line will raise an AttributeError because __apply_fees is private
account.__apply_fees()

Attempting to call the apply_fees method will result in an error:

AttributeError: 'Account' object has no attribute '__apply_fees'

In this Python example:

Constructor and Private Attribute: The __init__ method initializes an Account instance with an initial balance. The __balance attribute is marked as private.
Public Methods: We define public methods: get_balance and deposit (to add funds). These methods allow controlled access to the private __balance.
Private Method: The __apply_fees method is marked as private. It deducts a fixed fee from the account balance.
Usage: We create an account instance, deposit money, and print the balance. Attempting to call __apply_fees raises an AttributeError due to its private status.

Summary

Both examples demonstrate encapsulation by hiding implementation details and providing controlled access to data and methods. Rust achieves encapsulation through module visibility, while Python uses name mangling and access modifiers
Both Rust and Python support encapsulation, but they implement it in ways that reflect their language design principles and paradigms. Rust's approach is more explicit and enforced by the language, while Python's approach is more flexible but relies on convention and name mangling.
It's important to remember that Python's approach to encapsulation is more about convention and best practices rather than strict language enforcement.

Useful articles:

Image created by Bing and edited by me

Bitwise OR/AND operations

Antonov Mike — Sun, 31 Mar 2024 14:26:44 +0000

I've always had a poor understanding of bitwise operations. I read two interesting articles and decided to remember how poorly I understand all this stuff. I still don't understand this topic very well, because I don't use it at all, but now I can (if I strain my brain very hard) do this useless nonsense.
The articles:

Bitwise or | and bitwise and & are operations that compare two numbers bit by bit and return a new number in which each bit is 1 if both corresponding bits in the original numbers are 1 (for bitwise and) or at least one of them is 1 (for bitwise or).
When we perform a bitwise AND operation, we compare each corresponding bit of the two numbers. If both bits are 1, the result bit is 1; otherwise, it’s 0. For example, 3 | 4 equals 7 because 3 is in binary 0011, 4 is in binary 0100, and 7 is in binary 0111. Similarly, 3 & 4 is equal to 0 because no bit is equal to 1 in both numbers.
I wrote an example in Python and Rust. In both examples functions byte_shift_a and byte_shift_b take one argument a and returns the result of the operation a | b or a & b.

Rust example

Rust is statically typed and supports closures that can capture their environment, while Python is dynamically typed and uses functions for similar purposes.

fn main() {
    let b: u8 = 3;

    println!("SHIFT A:");
    for i in 0..12 {
        byte_shift_a(b, i)
    }

    println!("\nSHIFT B:");
    for i in 0..12 {
        byte_shift_b(b, i)
    }

    println!()
}

fn byte_shift_a(b: u8, num: u8) {
    let c = |a: u8| a | b;
    print!("{}: {}\t", num, c(num))
}

fn byte_shift_b(b: u8, num: u8) {
    let c = |a: u8| a & b;
    print!("{}: {}\t", num, c(num))
}

Python example

Python does not have a direct equivalent of Rust's closures, but we can achieve similar functionality using nested functions or lambda functions. This Python code should produce the same output as the original Rust code when executed.

def byte_shift_a(b, num):
    c = lambda a: a | b
    print(f"{num}: {c(num)}\t", end="")

def byte_shift_b(b, num):
    c = lambda a: a & b
    print(f"{num}: {c(num)}\t", end="")

b = 3

print("SHIFT A:")
for i in range(12):
    byte_shift_a(b, i)

print("\nSHIFT B:")
for i in range(12):
    byte_shift_b(b, i)

print()

Both examples will print the same

OUTPUT:
SHIFT A:
0: 3    1: 3    2: 3    3: 3    4: 7    5: 7    6: 7    7: 7    8: 11   9: 11   10: 1111: 11    
SHIFT B:
0: 0    1: 1    2: 2    3: 3    4: 0    5: 1    6: 2    7: 3    8: 0    9: 1    10: 211: 3

P.S.

It is also possible to use nested functions within byte_shift_a and byte_shift_b. For example:

def byte_shift_a(b, num):
    def c(a):
        return a | b
    print(f"{num}: {c(num)}\t", end="")

def byte_shift_b(b, num):
    def c(a):
        return a & b
    print(f"{num}: {c(num)}\t", end="")

How to put SOLID principles into practice

Antonov Mike — Tue, 26 Mar 2024 16:28:24 +0000

Introduction

This article is a continuation of my previous one (“How can applying the SOLID principles make the code better?”) and aims to show the implementation of SOLID principles using the example of an application architecture that is closer to real life, although it is still a demo. The implementation of a scooter rental system will be used for example.

This article uses two branches from my repository on GitLab. One demonstrates a starting point for building simple relationships between classes. The second shows the development of this idea through adding extra conditions.

1 Basic architecture

Link to the full version of the code for this chapter

The system should allow for the management of scooters, including their statuses. This includes the ability to change the status of a scooter (e.g., from available to rented) and to check the current status of a scooter.
Clients should be able to rent scooters, and employees should be able to service scooters.
System should be able to change scooter’s status. For example, a scooter can be reserved, rented or serviced.

Now let’s look how it is implemented:

Scooter Class

class Scooter:
    def __init__(self, status):
        self.status = status
        self.logger = logging.getLogger(__name__)

    def change_status(self, new_status):
        self.status = new_status
        self.logger.info(f"Scooter status changed to {new_status}")

    def is_available(self):
        return self.status == ScooterStatus.AVAILABLE

SRP: The Scooter class has a single responsibility, which is to manage the status of a scooter. It encapsulates the logic related to changing the status and logging relevant information. The change_status method handles only one aspect of the scooter’s behavior.
OCP: The Scooter class is not explicitly open for extension or closed for modification. However, it adheres to the OCP because its behavior can be extended by creating new subclasses without modifying the existing code.

ClientInterface and EmployeeInterface Abstract Classes:

class ClientInterface(ABC):
    @abstractmethod
    def rent_scooter(self, scooter, status_checker):
        """Rent a scooter."""
        pass

class EmployeeInterface(ABC):
    @abstractmethod
    def service_scooter(self, scooter, status_checker):
        """Service a scooter."""
        pass

ISP: These abstract classes define specific methods (rent_scooter for clients and service_scooter for employees) that adhere to the ISP. Clients and employees only need to implement the relevant methods, avoiding unnecessary dependencies.

Client and Employee Classes:

class Client(ClientInterface):
    def __init__(self):
        self.logger = logging.getLogger(__name__)

    def rent_scooter(self, scooter, status_checker):
        scooter.change_status("rented")
        self.logger.info("Scooter rented by client")

class Employee(EmployeeInterface):
    def __init__(self):
        self.logger = logging.getLogger(__name__)

    def service_scooter(self, scooter, status_checker):
        scooter.change_status("service")
        self.logger.info("Scooter serviced by employee")

SRP: Both classes have a single responsibility: Client rents a scooter, and Employee services a scooter. Their methods are focused on their respective tasks.
OCP: These classes are open for extension because they can be subclassed to add more behavior (e.g., additional client or employee actions) without modifying the existing code.

Example Usage (main.py)

from scooter import Scooter, Client, Employee, ScooterStatus, ScooterStatusChecker

scooter = Scooter(ScooterStatus.AVAILABLE)
print(scooter.is_available())

client = Client()
employee = Employee()
status_checker = ScooterStatusChecker()

client.rent_scooter(scooter, status_checker)

employee.service_scooter(scooter, status_checker)

scooter.change_status(ScooterStatus.AVAILABLE)
print(scooter.is_available())

Now let's get this skeleton up and running.

Extended architecture

Link to the full version of the code for this chapter

The system should ensure that a scooter can only be rented if it is available and that it can only be serviced if it is not currently rented.
The system should support different types of rentals, such as regular rentals, discounted rentals, and service rentals. Each type of rental should have it's own logic for changing the scooter's status.
It should be designed to be flexible, maintainable, and scalable, adhering to the SOLID principles. It should support different types of rentals, can be easily extended to support new rental types, and depends on abstractions rather than concrete implementations.

ClientInterface and EmployeeInterface Abstract Classes:

class Client(ClientInterface):
    def __init__(self):
        self.logger = logging.getLogger(__name__)
        self.rental_manager = RentalManager()

    def rent_scooter(self, scooter, status_checker):
        if status_checker:
            rental_type = self.rental_manager.determine_rental_type()
            rental = self.rental_manager.create_rental_instance(rental_type, scooter)
            rental.rent()
            self.logger.info("Scooter rented by client")
        else:
            self.logger.error(f"Scooter is unavailable for rent: {scooter.status}")

class Employee(EmployeeInterface):
    def __init__(self):
        self.logger = logging.getLogger(__name__)

    def service_scooter(self, scooter, status_checker):
        if status_checker:
            scooter.change_status("service")
            self.logger.info("Scooter serviced by employee")
        else:
            self.logger.error(f"Unawailable for service: {scooter.status}")

ISP: The methods of this class have been extended, but they are still define specific methods, and clients and employees only need to implement the relevant methods, avoiding unnecessary dependencies.

RentalManager

class RentalManager:
    def __init__(self):
        self.logger = logging.getLogger(__name__)

    def determine_rental_type(self):
        current_hour = datetime.now().hour
        if 6 <= current_hour < 18:
            return RentType.REGULAR
        else:
            return RentType.DISCOUNTED

    def create_rental_instance(self, rental_type, scooter):
        if rental_type == RentType.REGULAR:
            return RegularRental(scooter)
        elif rental_type == RentType.DISCOUNTED:
            return DiscountedRental(scooter)
        else:
            raise ValueError("Invalid rental type")

DIP: RentalManager class depends on the abstraction of the Rental class rather than concrete implementations like RegularRental or DiscountedRental. This is evident in the create_rental_instance method, where it decides which type of rental to create based on the rental type, without needing to know the specifics of how each rental type is implemented. This design allows for flexibility and makes it easier to add new types of rentals in the future without modifying the RentalManager class.

Example Usage (main.py)

from scooter import (
    Scooter,
    Client,
    Employee,
    RegularRental,
    DiscountedRental,
    RentalSystem,
    ServiceRental,
    ScooterStatus,
    ScooterStatusChecker,
)

scooter = Scooter(ScooterStatus.AVAILABLE)
client = Client()
employee = Employee()
status_checker = ScooterStatusChecker()

# Client rents a scooter
client.rent_scooter(scooter, scooter.is_available())
# Client tries to rent rented scooter
client.rent_scooter(scooter, scooter.is_available())
# Employee tries to service rented scooter
employee.service_scooter(scooter, scooter.is_available())
# Termination of rent
scooter.change_status(ScooterStatus.AVAILABLE)
# Employee services a scooter
employee.service_scooter(scooter, scooter.is_available())
print("Client tries to rent scooter while it is in services")
client.rent_scooter(scooter, scooter.is_available())

Conclusion

If we make the assumption that the application architecture was developed based on the specification, we can now move on to writing the business logic. For this purpose we need business requirements. Requirements should be designed to leverage the existing code structure and provide a comprehensive set of features for managing a scooter rental system effectively. They can be further refined and expanded based on additional features or specific business needs.
Example:

User Authentication:

Implement a user authentication system that interfaces with the Client class to verify identity before allowing scooter rental.

Scooter Availability Check:

Utilize the is_available method in the Scooter class to check scooter availability in real-time before a client can rent it.

Status Update Notifications:

Integrate a notification system that uses the change_status method to inform users of status updates on their rented scooters.

Maintenance Workflow:

Use the Employee class to create a workflow for regular scooter maintenance and servicing, triggered by the service_scooter method.

Dynamic Pricing:

Develop a dynamic pricing strategy that can be applied in the RegularRental and DiscountedRental classes based on factors like demand, time of day, and special promotions.

Battery Level Monitoring:

Incorporate a feature that monitors and reports the battery level of scooters, tying into the LOW_BATTERY status.

Damage Reporting:

Allow users to report scooter malfunctions or damages, which would change the scooter's status to MALFUNCTION and trigger a service workflow.

Lost Scooter Tracking:

Implement a system to track and manage scooters that are marked as LOST.

Rental History:

Create a rental history feature that logs all rental activities associated with a user, utilizing the rent method in the Rental classes.

Customer Support Integration:

Set up a customer support system that can interface with the Client class to handle queries and issues.

This is just an example of business requirements. In real life, the requirements will of course be very different.

Outroduction

I hope these two examples (basic architecture and extended architecture) of creating an application using SOLID principles will be useful to someone.

P.S.

I will be glad to comments, corrections and additions in the comments, if they will be stated in an acceptable form, and if in an unacceptable form, I will be glad too, but less so 😅

Take care

How can applying the SOLID principles make the code better?

Antonov Mike — Tue, 19 Mar 2024 16:14:21 +0000

Applying the SOLID principles to your code can significantly enhance its quality, making it more understandable, flexible, maintainable, and scalable. Here's how each principle contributes to improving code quality:

1. Single Responsibility Principle (SRP)

The Single Responsibility Principle states that a class should have only one reason to change. This principle aims to separate behaviours so that if bugs arise as a result of your change, it won’t affect other unrelated behaviours.
If each class has only one reason to change, you make the code easier to maintain. Changes are more localized, reducing the risk of introducing bugs. And since the responsibilities of each class are more clearly defined, such code is easier to read.
No SRP

class User:
    def __init__(self, name, email):
        self.name = name
        self.email = email

    def save(self):
        pass

    def send_email(self):
        pass

SRP

class User:
    def __init__(self, name, email):
        self.name = name
        self.email = email

class UserRepository:
    def save(self, user):
        pass

class EmailService:
    def send_email(self, user):
        pass

To address business responsibilities, we might consider what business logic or rules apply to the User and how they can be encapsulated within a class.

2. Open/Closed Principle (OCP)

Classes should be open for extension, but closed for modification. This means that you should be able to add new functionality without changing the existing code.
OCP allows new functionality to be added without modifying existing code, making the system more adaptable to change. And you minimize the risk of introducing bugs when extending the functionality of your system.

from abc import ABC, abstractmethod

class Payment(ABC):
    @abstractmethod
    def process_payment(self, amount):
        pass

class CreditCardPayment(Payment):
    def process_payment(self, amount):
        print(f"Processing credit card payment of {amount}")

class OnlinePayment(Payment):
    def process_payment(self, amount):
        print(f"Processing online payment of {amount}")

class CryptoCurrencyPayment(Payment):
    def process_payment(self, amount):
        print(f"Processing crypto payment of {amount}")

# New class that uses a specific payment method passed as an argument
class PaymentProcessing:
    def concrete_payments(self, payment_method: Payment, amount):
        payment_method.process_payment(amount)

credit_card_payment = CreditCardPayment()
some_object = PaymentProcessing()
some_object.concrete_payments(credit_card_payment, 100)

online_payment = OnlinePayment()
some_object.concrete_payments(online_payment, 200)

crypto_payment = CryptoCurrencyPayment()
some_object.concrete_payments(crypto_payment, 300)

3. Liskov Substitution Principle (LSP)

The Liskov Substitution Principle states that if a program is using a base class, it should be able to use any of its subclasses without the program knowing it. In other words, the subclasses should be substitutable for their base class.
LSP ensures that subclasses can be used in place of their base classes without altering the correctness of the program, making the code more robust. In addition, you can reuse code because code that works with the base class will also work with any of its subclasses.
No LSP

class Rectangle:
    def __init__(self, width, height):
        self.width = width
        self.height = height

    def area(self):
        return self.width * self.height

    def set_width(self, width):
        self.width = width

    def set_height(self, height):
        self.height = height

class Square(Rectangle):
    def __init__(self, side):
        super().__init__(side, side)

    def set_side(self, side):
        self.width = side
        self.height = side

LSP

class Shape:
    def area(self):
        pass

class Rectangle(Shape):
    def __init__(self, width, height):
        self.width = width
        self.height = height

    def area(self):
        return self.width * self.height

class Circle(Shape):
    def __init__(self, radius):
        self.radius = radius

    def area(self):
        return 3.14 * (self.radius ** 2)

4. Interface Segregation Principle (ISP)

The Interface Segregation Principle states that no client should be forced to depend on interfaces they do not use. This means that a class should not have to implement methods it doesn't use. Clients should not be forced to depend on methods that they do not use.
By ensuring that interfaces are small and focused, so classes are not forced to depend on interfaces they do not use. This makes the system more flexible and adaptable to change.
No ISP

class Worker:
    def work(self):
        pass

    def eat(self):
        pass

class Robot(Worker):
    def work(self):
        pass

    def eat(self):
        raise NotImplementedError("Robots don't eat.")

ISP

class Worker:
    def work(self):
        pass

class Eater:
    def eat(self):
        pass

class Human(Worker, Eater):
    def work(self):
        pass

    def eat(self):
        pass

class Robot(Worker):
    def work(self):
        pass

5. Dependency Inversion Principle (DIP)

High-level modules depend on abstractions rather than on low-level modules. This makes the code more flexible and easier to understand. It becomes easier to write unit tests for individual components. Each component can be tested in isolation, without needing to consider the behavior of other components.
No DIP

class LightBulb:
    def __init__(self):
        self.is_on_state = False

    def turn_on(self):
        self.is_on_state = True
        print("Light is on")

    def turn_off(self):
        self.is_on_state = False
        print("Light is off")

    def is_on(self):
        return self.is_on_state


class ElectricPowerSwitch:
    def __init__(self):
        self.light_bulb = LightBulb()

    def press(self):
        if self.light_bulb.is_on():
            self.light_bulb.turn_off()
        else:
            self.light_bulb.turn_on()


switch = ElectricPowerSwitch()

switch.press()
switch.press()

DIP

from abc import ABC, abstractmethod


class Switchable(ABC):
    @abstractmethod
    def turn_on(self):
        pass

    @abstractmethod
    def turn_off(self):
        pass

    @abstractmethod
    def is_on(self):
        pass


class LightBulb(Switchable):
    def __init__(self):
        self.is_on_state = False

    def turn_on(self):
        self.is_on_state = True
        print("Light is on")

    def turn_off(self):
        self.is_on_state = False
        print("Light is off")

    def is_on(self):
        return self.is_on_state


class ElectricPowerSwitch:
    def __init__(self, switchable: Switchable):
        self.switchable = switchable

    def press(self):
        if self.switchable.is_on():
            self.switchable.turn_off()
        else:
            self.switchable.turn_on()


light_bulb = LightBulb()
switch = ElectricPowerSwitch(light_bulb)

switch.press()
switch.press()

Conclusion

By adhering to the SOLID principles, developers aim to create a system that is easy to understand, easy to change, and easy to maintain. These principles guide the design of software in a way that is robust, flexible, and adaptable to future changes. They help in creating a system that is not only functional but also scalable and maintainable, making it a better choice for long-term projects.

Image created by Bing

Next part: How to put SOLID principles into practice

Abstraction in Rust and Python. Simple examples

Antonov Mike — Tue, 27 Feb 2024 12:49:12 +0000

Disclaimer

The article contains code samples, but not theory and does not pretend to explain the theoretical basis of polymorphism in depth, nor does it explain why and when polymorphism should be used.
The article demonstrates how to implement abstraction in Rust and Python, but does not explain practical applications of polymorphism in real projects.

Abstraction

Abstraction is a fundamental concept in both Rust and Python, allowing for the encapsulation of complex implementations behind simpler interfaces. This makes code more modular, easier to maintain, and helps in reducing the complexity of the system. Let's explore how abstraction works in both languages with a simple example.

In Rust

we can use traits to define a contract for what a class should do without specifying how it does it. This is a form of abstraction. Here's a basic example:

// Define a trait named `Printer`
trait Printer {
    // Declare a method `print_data` that takes a string slice and returns nothing
    fn print_data(&self, data: &str);
}

// Implement the `Printer` trait for a struct named `DataPrinter`
struct DataPrinter;

impl Printer for DataPrinter {
    fn print_data(&self, data: &str) {
        println!("Data: {}", data);
    }
}

fn main() {
    let printer = DataPrinter;
    printer.print_data("Hello, Rust!");
}

In this Rust example, Printer is an abstraction that defines a print_data method. The DataPrinter struct implements this trait, providing the actual implementation of print_data. The main function doesn't need to know how print_data is implemented; it only needs to know that DataPrinter is a Printer. The print_data method in the Printer trait is declared but does nothing. This method is then implemented in the DataPrinter struct to print the data. This setup allows for the possibility of other structs implementing the Printer trait with their own implementations of print_data, or they could use the default (no-op) implementation if they don't need to print anything.

In Python

it's more about encapsulation and duck typing because Python is a dynamically typed language. Here's how you might achieve a similar effect to the Rust example:

class Printer:
    def print_data(self, data):
        raise NotImplementedError("Subclasses must implement this method")

class DataPrinter(Printer):
    def print_data(self, data):
        print(f"Data: {data}")

def main():
    printer = DataPrinter()
    printer.print_data("Hello, Python!")

if __name__ == "__main__":
    main()

In this Python example, Printer is an abstract base class (ABC) that defines a print_data method. The DataPrinter class inherits from Printer and provides an implementation for print_data. The main function uses a DataPrinter instance without needing to know the details of how print_data is implemented.

Summary

Both Rust and Python support abstraction, allowing you to hide the complexity of an implementation behind a simpler interface. Rust achieves this through traits, which are a way to define shared behavior across types, while Python uses abstract base classes (ABCs) and duck typing to achieve a similar effect. The key takeaway is that both languages allow you to define a contract for what a class should do without specifying how it does it, making your code more modular and easier to maintain.

Polymorphism in Rust and Python. Simple examples

Antonov Mike — Fri, 23 Feb 2024 14:13:56 +0000

Disclaimer

The article contains code samples, but not theory and does not pretend to explain the theoretical basis of polymorphism in depth, nor does it explain why and when polymorphism should be used.
The article demonstrates how to implement polymorphism in Rust and Python, but does not explain practical applications of polymorphism in real projects.

Polymorphism

allows you to write code that can work with different types of objects that share some common behavior or interface. For example, you can write a function that can accept any object that can make a sound, such as a dog, a cat, or a bird.

In Rust

one way to achieve polymorphism is to use traits and generics. Traits define a set of methods that a type must implement to satisfy a certain interface. Generics allow you to write code that can work with any type that meets some trait bounds. For example, you can write a function that can accept any type that implements the SoundMaker trait, which defines a method called make_sound. Here is an example of polymorphism in Rust using traits and generics:

// Define a trait that requires a method called make_sound
trait SoundMaker {
    fn make_sound(&self);
}

// Implement the trait for different types
impl SoundMaker for String {
    fn make_sound(&self) {
        println!("{} says hello", self);
    }
}

impl SoundMaker for i32 {
    fn make_sound(&self) {
        println!("{} beeps", self);
    }
}

// Write a generic function that can accept any type that implements the trait
fn make_some_sound<T: SoundMaker>(item: T) {
    item.make_sound();
}

// Call the function with different types
fn main() {
    let name = String::from("Alice");
    let number = 42;
    make_some_sound(name); // Alice says hello
    make_some_sound(number); // 42 beeps
}

In Python

one way to achieve polymorphism is to use duck typing and inheritance. Duck typing is a concept that says that an object's behavior is more important than its type. In other words, if an object can do something, it doesn't matter what type it is. Inheritance is a concept that allows a class to inherit the attributes and methods of another class. For example, you can write a function that can accept any object that has a method called make_sound. Here is an example of polymorphism in Python using duck typing and inheritance:

# A class that has a method called make_sound
class SoundMaker:
    def make_sound(self):
        pass

# A subclasses that inherit from the base  class and override the method
class String(SoundMaker):
    def __init__(self, value):
        self.value = value

    def make_sound(self):
        print(f"{self.value} says hello")

class Integer(SoundMaker):
    def __init__(self, value):
        self.value = value

    def make_sound(self):
        print(f"{self.value} beeps")

# A function that can accept any object that has a method called make_sound
def make_some_sound(item):
    item.make_sound()

# Call the function with different objects
name = String("Alice")
number = Integer(42)
make_some_sound(name)  # Alice says hello
make_some_sound(number)  # 42 beeps

Conclusion

As you can see, the examples are similar in the sense that they both use a common interface (make_sound) to achieve polymorphism. However, they also differ in the syntax and the concepts they use. Rust is more explicit and type-safe, while Python is more dynamic and flexible. Both languages have their own advantages and disadvantages, depending on the use case and the preference of the programmer.

Odoo security concept

Antonov Mike — Mon, 05 Feb 2024 05:27:21 +0000

/*Disclaimer

I haven't written tutorials for a few years,  and 
recently a fellow friend advised me to learn Odoo 
and look for a job in this field, so I decided to 
practice and rewrite Odoo  security concept in  a 
different style. I'm sure  I've lost the skill to 
do this  kind of  work and might have missed some 
details.  In any case,  reasoned  criticism in an 
acceptable form is welcome.*/

Sources:

General Info

The security concept in Odoo is based on the mechanism of user groups and access rights. Access rights define which users can view, create, modify or delete records in the database. User groups unite users with common access rights. A user can belong to multiple groups, and each group can have its own access rights.

Access Rights

These are access rights that define what operations (create, read, update, delete) a user can perform on data models. Access Rights are applied at the model level, i.e. to all records in the model. Access Rights are defined in the file ir.model.access.access.csv, which must be located in the security folder of the module. The file ir.model.access.csv contains the following fields:

id – unique identifier of access right
name – access right description
model_id – model to which the right of access applies
group_id – user group to which the right of access is granted
perm_read – read permission (1 or 0)
perm_write – update permission (1 or 0)
perm_create – create permission (1 or 0)
perm_unlink – delete permission (1 or 0) For example, to give the "Library / User" user group the right to read and create books, but not to update and delete them, you can add the following line to the file ir.model.access.csv:

id	name	model_id:id	group_id:id	perm_read	perm_write	perm_create	perm_unlink
access_library_book_user	library.book.user	model_library_book	library.group_library_user	1	0	1	0

When No Access Rights Are Specified

If we run the program without defined access rights for a module, we will see a warning in the terminal, for example, the following:

2024-02-02 11:48:53,572 2533261 WARNING rd-mydb odoo.modules.loading: 
The models ['estate_property'] have no access rules in module estate, 
consider adding some, like:
id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink
estate.access_estate_property,access_estate_property,estate.model_estate_property,base.group_user,1,0,0,0

To add access rights for a module, you must create a file named ir.model.access.csv in the security folder of the current module, for example estate/security/ir.model.access.csv. In this file, you can define different access rights for different user groups. For example, you can define that the user group "managers" has the right to read, write and delete records, while the user group "users" has only the right to read.

Access rights without groups

Creating access rights

You can define access rights in the file security/ir.model.access.csv using the following format:

id	name	model_id:id	group_id:id	perm_read	perm_write	perm_create	perm_unlink
access_estate_property_user	access_estate_property_user	model_estate_property		1	0	0	0
access_estate_property_manager	access_estate_property_manager	model_estate_property		1	1	1	1

If there is an entry in the group_id field, for example group_estate_manager or estate.group_estate_manager, then the rules for it are defined in the security/security.xml file. But for now we'll leave the group_id field empty, so that the rule will apply to all users.
In this example we define two types of access: one for regular users (access_estate_property_user), which is read-only (perm_read=1), and one for managers (access_estate_property_manager), which has all permissions.
Once this file is created, you need to make sure it is included in the manifest of the current module. Add the file path to the 'data' section of the manifest.
File estate/__manifest__.py:

{
    ...
    'data': [
        'security/ir.model.access.csv'
    ],
    ...
}

Installing or updating a module

Odoo will automatically apply these access rights to the appropriate data models. For example, you can use the command to update -u estate:

./odoo-bin --addons-path="addons, custom" -d rd-mydb -u estate

If you have correctly created access rights for your module, the warning will no longer appear in the terminal.

Csv fields, identifiers and references

Fields of the csv file

The "id" and "name" fields in the ir.model.access.csv file are required and they must be unique. They are used to identify the access rule.

"id"

This is a unique identifier for the access rule. You can choose any value, but it must be unique in the context of the entire ir.model.access.csv file. In our case, access_estate_property_user and access_estate_property_manager are unique identifiers for two different access rules.

"name"

This is the name for the access rule. It is usually the same as "id", but can be different if you want to use a name that describes the rule in more detail. In our case, access_estate_property_user and access_estate_property_manager are also names for two different access rules.

"model_id:id"

Refers to the data model to which the access rule applies. In our case, model_estate_property is a reference to the data model that was defined in the "TestModel" class using the _name attribute.
File estate/models/estate_test.py:

class TestModel(models.Model):
    _name = "estate_property"

"group_id:id"

Refers to the user group to which the access rule applies. If this field is left empty, the rule applies to all users. This may be convenient for testing, but in real situations it is necessary to restrict access to the model for certain groups of users. For this purpose you can use existing groups from the base module, for example, base.group_user or base.group_system, or you can create your own groups in the file security.xml.

Identifiers

In Odoo, model_id:id and group_id:id are used to refer to external model and group identifiers. The : is used to separate the name of the external identifier (model_id or group_id) from the identifier itself.
The usual way of naming a model in Odoo is model_<model_name>, where <model_name> is the _name of the model, where . is replaced by _. For example, sale.order becomes model_sale_order.
Similarly, group_id:id refers to the group that will apply the access right. The value of id here is the group's external identifier, which was created automatically when the group was created. This approach allows you to reference a model or group without knowing their internal identifiers in the database.

Reference to a group

The reference can be either to a group within the "estate" module (group_estate_manager), or to the same group but from another module (estate.group_estate_manager). The format group_estate_manager without the module prefix is usually used within a module where it refers to a group defined in the current module. In the latter case, estate is the name of the module and group_estate_manager is the group identifier within that module.

Access rights for groups

Creating a "group_id"

Instead of using existing groups from the base module, such as base.group_user or base.group_system, you can create your own groups:

In estate/security/security.xml create two user groups using the <record> tag and specify their IDs, names, categories, and parent groups (if any):

<odoo>
  <record id="group_estate_manager" model="res.groups">
    <field name="name">Estate Manager</field>
    <field name="category_id" ref="base.module_category_hidden"/>
    <field name="implied_ids" eval="[(4, ref('base.group_user'))]"/>
  </record>

  <record id="group_estate_user" model="res.groups">
    <field name="name">Estate User</field>
    <field name="category_id" ref="base.module_category_hidden"/>
    <field name="implied_ids" eval="[(4, ref('base.group_user'))]"/>
  </record>
</odoo>

The parent groups for each of the created groups group_estate_manager and group_estate_user are specified here. This is done using the implied_ids field. For each group, it is specified that they include the base.group_user group, which is the default user group in Odoo. So any user who is in the group_estate_manager or group_estate_user group will automatically also be in the base.group_user group.

In the file estate/security/ir.model.access.csv set external identifiers for user groups estate.group_estate_manager и estate.group_estate_user:

id	name	model_id:id	group_id:id	perm_read	perm_write	perm_create	perm_unlink
access_estate_property_user	access_estate_property_user	model_estate_property	group_estate_user	1	0	0	0
access_estate_property_manager	access_estate_property_manager	model_estate_property	group_estate_manager	1	1	1	1

In the estate/manifest.py file, add the paths to the files estate/security/security.xml and estate/security/ir.model.access.csv to the 'data' list so that they will be loaded when the module is installed:

'data': [
    'security/security.xml',
    'security/ir.model.access.csv',
],

Then restart Odoo with a command like
./odoo-bin --addons-path="addons, custom" -d rd-mydb -u estate
The module is now running with updated access rights.

Example of demo module

File custom/estate/models/estate_test.py

from odoo import fields, models

class TestModel(models.Model):
    _name = "estate_property"
    _description = "Estate test module"

    name = fields.Char(required=True)
    description = fields.Text()
    postcode = fields.Char()
    date_availability = fields.Date()
    expected_price = fields.Float(
        required=True, 
        help="Some helpful information")
    selling_price = fields.Float()
    bedrooms = fields.Integer()
    living_area = fields.Integer()
    facades = fields.Integer()
    garage = fields.Boolean()
    garden = fields.Boolean()
    garden_area = fields.Integer()
    garden_orientation = fields.Selection(
        string="Type",
        required=False,
        selection=[('south', 'South'),
                   ('north', 'North'),
                   ('east', 'East'),
                   ('west', 'West')],
    )

File custom/estate/__manifest__.py

{
    'name': "estate",
    'version': '1.0',
    'license': 'LGPL-3',
    'depends': ['base'],
    'author': "Author Name",
    'category': 'Estate',
    'description': """
    Description Text
    """,
    # data files always loaded at installation
    'data': [
        'security/security.xml',
        'security/ir.model.access.csv',
        'views/estate_view.xml',
        'views/estate_menu.xml',
    ],
    # data files containing optionally loaded demonstration data
    'demo': [],
}

File custom/estate/__init__.py

from . import models

File custom/estate/models/__init__.py

from . import estate_test

File security/security.xml

<odoo>
  <record id="group_estate_manager" model="res.groups">
    <field name="name">Estate Manager</field>
    <field name="category_id" ref="base.module_category_hidden"/>
    <field name="implied_ids" eval="[(4, ref('base.group_user'))]"/>
  </record>

  <record id="group_estate_user" model="res.groups">
    <field name="name">Estate User</field>
    <field name="category_id" ref="base.module_category_hidden"/>
    <field name="implied_ids" eval="[(4, ref('base.group_user'))]"/>
  </record>
</odoo>

File security/ir.model.access.csv

id	name	model_id:id	group_id:id	perm_read	perm_write	perm_create	perm_unlink
access_estate_property_user	access_estate_property_user	model_estate_property	group_estate_user	1	0	0	0
access_estate_property_manager	access_estate_property_manager	model_estate_property	group_estate_manager	1	1	1	1

Burning Flask Tutorial

Antonov Mike — Thu, 04 Jan 2024 07:04:27 +0000

Completed all the Flask tasks from their official website and here is straight up no satisfaction at all. Looks like I burned out before I even got the job. Two years of pointless studying of Rust clearly took a toll on me. I wonder why I can still do stuff.
I don't know how to do frontend, so it doesn't look nice. But I don't like frontend either. To me, the more backend the better.
Without feedback on the work done, I don't know how well I did, because I don't know the market requirements.

Image created by Bing

DEV Community: Antonov Mike

TypeScript warnings

Event Loop: Call Stack, Web API, Task Queue, Microtask Queue

Main components of the Event Loop:

Step-by-step explanation:

Conclusion:

Odoo General settings: Technical

Discuss

Sub-menus:

Email

Sub-menus:

Phone / SMS

Sub-menus:

Mass Mailing

Sub-menus:

Actions

Sub-menus:

IAP

Sub-menus:

User Interface

Sub-menus:

Database Structure

Sub-menus:

Automation

Sub-menus:

Reporting

Sub-menus:

Sequences & Identifiers

Sub-menus:

Parameters

Sub-menus:

Security

Sub-menus:

Privacy

Sub-menus:

Resource

Sub-menus:

Calendar

Sub-menus:

Composition in Rust and Python

Disclaimer

Introduction

Rust Example

Python Example

So what are the differences?

These articles may be useful

Other articles about the similarities and differences between Rust and Python

Encapsulation in Rust and Python

Disclaimer

Introduction

Encapsulation in Rust

In this Rust example:

Python Example

In this Python example:

Summary

Useful articles:

Encapsulation in Rust

Encapsulation in Python

Rust + Python:

Other articles about the similarities and differences between Rust and Python

Bitwise OR/AND operations

Rust example

Python example

Both examples will print the same

P.S.

How to put SOLID principles into practice

Introduction

1 Basic architecture

Scooter Class

ClientInterface and EmployeeInterface Abstract Classes:

Client and Employee Classes:

Example Usage (main.py)

Extended architecture

ClientInterface and EmployeeInterface Abstract Classes:

RentalManager

Example Usage (main.py)

Conclusion

User Authentication:

Scooter Availability Check:

Status Update Notifications: