[fix] Dynamically updating notification verb #334

[pranshustuff]

Checklist

• I have read the OpenWISP Contributing Guidelines.
• I have manually tested the changes proposed in this pull request.
• I have written new test cases for new code and/or updated existing tests for changes to existing code.
• I have updated the documentation.

Reference to Existing Issue

Fixes #334.

Description of Changes

• Made verb field in notification nullable.
• Added a property verb under AbstractNotification in models that uses configured value from NOTIFICATION_TYPES and uses DB value as a fallback if that fails.

Screenshot

simplescreenrecorder-2025-10-01_15.25.40.mp4

[pranshustuff]

I think the CI builds are failing because the ./manage.py makemigrations isn't being run in the workflow, the migration I added solved the issue of the NOT NULL constraint on verb when I tested locally.

[nemesifier]

Thanks @pranshustuff.

We need a test which replicates the bug described in #334. The test should fail without your patch and should pass with it.

Please also make sure the CI build passes.

See more comments below.

[pranshustuff]

I've made the requested changes.

[nemesifier]

Tests and QA checks are failing, the developer docs of OpenWISP RADIUS explain how to run tests and QA checks.

[pranshustuff]

Ok locally, it passed the tests, on sample app too. I added a test that mimics the bug in test_notifications.py.

[pranshustuff]

I made the requested changes.
The property is now called resolved_verb which gets verb from config and falls back to verb if config.get() fails. I changed many instances of .verb to .resolved_verb in the tests, so the tests mimic the logic too. And verb field is not being removed, it is being altered to nullable.

[pandafy]

This will break the existing integration with other OpenWISP apps.

We have a context manager notification_render_attributes , Can we set the verb using notification type in the context manage and then clear the field (set to None) in cleanup process?

openwisp-notifications/openwisp_notifications/base/models.py

Lines 45 to 81 in b356e1d

	@contextmanager
	def notification_render_attributes(obj, **attrs):
	"""
	This context manager sets temporary attributes on
	the notification object to allowing rendering of
	notification.
	It can only be used to set aliases of the existing attributes.
	By default, it will set the following aliases:
	- actor_link -> actor_url
	- action_link -> action_url
	- target_link -> target_url
	"""
	defaults = {
	"actor_link": "actor_url",
	"action_link": "action_url",
	"target_link": "target_url",
	}
	defaults.update(attrs)
	for target_attr, source_attr in defaults.items():
	setattr(obj, target_attr, getattr(obj, source_attr))
	# In Django 5.1+, GenericForeignKey fields defined in parent models can no longer
	# be overridden in child models (https://code.djangoproject.com/ticket/36295).
	# To avoid multiple database queries, we explicitly set these attributes here
	# using our cached _related_object method instead of relying on the default
	# GenericForeignKey accessor which would bypass our caching mechanism.
	setattr(obj, "actor", obj._related_object("actor"))
	setattr(obj, "action_object", obj._related_object("action_object"))
	setattr(obj, "target", obj._related_object("target"))
	yield obj
	for attr in defaults.keys():
	delattr(obj, attr)

It should behave similarly to the resolved_verb property.

db_verb = obj.verb
# we give preference to the verb stored in the database
verb = obj.verb or config.get('verb')

# In cleanup 
obj.verb = db_verb

Do you think a solution like this will solve our problem?

[pranshustuff]

I have not tested it yet. But I think it's a plausible solution.

I am a little busy at the moment. I'll get back to you sometime around next week after investigating this approach.

Thanks again for the review!