Skip to content

Refactor: Rename models to singular form and fix admin registration#643

Merged
regulartim merged 3 commits intointelowlproject:developfrom
srijan2607:refactor/rename-models-singular
Dec 23, 2025
Merged

Refactor: Rename models to singular form and fix admin registration#643
regulartim merged 3 commits intointelowlproject:developfrom
srijan2607:refactor/rename-models-singular

Conversation

@srijan2607
Copy link
Copy Markdown
Contributor

@srijan2607 srijan2607 commented Dec 22, 2025

Description

This pull request introduces a set of database model renames to improve naming consistency and clarity across the codebase. The models MassScanners, Sensors, and WhatsMyIP have been renamed to MassScanner, Sensor, and WhatsMyIPDomain respectively. All references throughout the application, admin interface, cronjobs, and tests have been updated accordingly. Additionally, a new migration is included to apply these changes to the database schema and indexes, and a minor improvement was made to the logging directory configuration.

Model Renaming and Migration:

  • Renamed models: MassScanners → MassScanner, Sensors → Sensor, WhatsMyIP → WhatsMyIPDomain in greedybear/models.py, and updated all usages throughout the codebase. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22]
  • Added migration 0023_rename_massscanners_massscanner_and_more.py to rename the models and associated indexes, and to update the Statistics model's view field choices.

Configuration Improvement:

  • The DJANGO_LOG_DIRECTORY setting now reads from the environment variable if set, with a default fallback, improving deployment flexibility.

Renamed Django models from plural to singular names to fix double-pluralization in the admin interface (e.g., "Sensorss").

Specific changes:

  • MassScanners -> MassScanner
  • Sensors -> Sensor
  • WhatsMyIP -> WhatsMyIPDomain

Updated all references in code (models.py, admin.py, cronjobs) and generated migrations.

Related issues

Closes #638

Type of change

  • Bug fix (non-breaking change which fixes an issue).
  • New feature (non-breaking change which adds functionality).
  • Breaking change (fix or feature that would cause existing functionality to not work as expected).

Checklist

  • I have read and understood the rules about how to Contribute to this project.
  • The pull request is for the branch develop.
  • I have added documentation of the new features.
  • Linters (Black, Flake, Isort) gave 0 errors.
  • I have added tests for the feature/bug I solved. All the tests (new and old ones) gave 0 errors.
  • If changes were made to an existing model/serializer/view, the docs were updated and regenerated (check CONTRIBUTE.md).
  • If the GUI has been modified:
    • I have a provided a screenshot of the result in the PR.
    • I have created new frontend tests for the new component or updated existing ones.

@srijan2607
Copy link
Copy Markdown
Contributor Author

srijan2607 commented Dec 22, 2025

@mlodic can you take a look

@regulartim
Copy link
Copy Markdown
Collaborator

regulartim commented Dec 22, 2025

Please fix the formatting @srijan2607

@srijan2607
Copy link
Copy Markdown
Contributor Author

srijan2607 commented Dec 22, 2025

@regulartim can you run the workflow once again ?

@regulartim
Copy link
Copy Markdown
Collaborator

regulartim commented Dec 22, 2025

First of all, thanks for your work! :) Two things:

  • You checked the box that this is a breaking change. Why do you think it is? Which functionality breaks by merging this?
  • The configuration improvement you propose might be a good idea but to be honest, I don't immediately see why. I would prefer if you follow our standard work process: Open an issue -> get assigned -> open a PR -> merge. In the issue you can describe why it would be a good idea to do it that way or why it is a problem if we don't. Then the decision process behind the code is traceable.

@srijan2607
Copy link
Copy Markdown
Contributor Author

srijan2607 commented Dec 23, 2025

Hi, @regulartim and thanks for the review!

On your questions:

Why this is a breaking change
I marked it as breaking because the model renames change import paths and class names across the codebase (e.g., MassScanners → MassScanner). Any external scripts/tools importing these models directly will break until updated. This PR also includes DB-level changes (table renames), which is a structural migration and not safely backward-compatible.

Config improvement (logging path)
You’re right that should be separated. While testing locally I hit a FileNotFoundError because the hardcoded /var/log path wasn’t writable, which blocked running migrations. To keep this PR focused, I’ll revert the settings.py changes here and open a separate issue to discuss making the log directory configurable (better local dev support, container friendliness, etc.).

I’ll revert the settings.py changes on this branch and push an update to the PR. I’ll also open the follow-up issue unless you’d prefer to create it yourself.

@srijan2607
Copy link
Copy Markdown
Contributor Author

srijan2607 commented Dec 23, 2025

@regulartim
Done! I've reverted the settings.py changes in the PR to keep the scope focused on the model rename. I'll open a separate issue to discuss the configuration improvements.

@srijan2607
Copy link
Copy Markdown
Contributor Author

srijan2607 commented Dec 23, 2025

@regulartim what is the best way to get in touch with you have some questions

@regulartim
Copy link
Copy Markdown
Collaborator

regulartim commented Dec 23, 2025

@regulartim what is the best way to get in touch with you have some questions

I suggest the honeynet slack: https://gsoc-slack.honeynet.org/

@regulartim
Copy link
Copy Markdown
Collaborator

regulartim commented Dec 23, 2025 •
edited
Loading

Why this is a breaking change
I marked it as breaking because the model renames change import paths and class names across the codebase (e.g., MassScanners → MassScanner). Any external scripts/tools importing these models directly will break until updated. This PR also includes DB-level changes (table renames), which is a structural migration and not safely backward-compatible.

Ok, then we just have different definitions of what is a breaking change and what is not (I'm not saying you're wrong). What's important to me right now is: if we merge your code and build a release, will updating my GreadyBear instance cause it to stop working? I think not. Do you agree?

@srijan2607
Copy link
Copy Markdown
Contributor Author

srijan2607 commented Dec 23, 2025

Make sense @regulartim it wont effect the working of the GreadyBear will keep this terminology in mind.

@regulartim
Copy link
Copy Markdown
Collaborator

regulartim commented Dec 23, 2025

I am not sure if my terminology is correct though. But for the purpose of this PR, this is was matters to me.

@regulartim regulartim merged commit bc66e45 into intelowlproject:develop Dec 23, 2025
5 checks passed
@srijan2607 srijan2607 deleted the refactor/rename-models-singular branch December 23, 2025 11:06
@opbot-xd opbot-xd mentioned this pull request Dec 30, 2025
Merged
10 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@regulartim regulartim regulartim approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@srijan2607 @regulartim