Benefit Features db modeling #1813
Conversation
| FOUNDATION = "psf" | ||
| PYCON = "pycon" | ||
| PYPI = "pypi" | ||
| CORE_DEV = "core" |
There was a problem hiding this comment.
We have other choice fields in the sponsors app, such as sponsorship's status or contract's status. For the sake of integrity, I'd like to refactor them to also use Enum too if you think it's a good idea.
There was a problem hiding this comment.
yes! i think this is a wonderful idea!
requirements.txt
Outdated
| @@ -1,2 +1,3 @@ | |||
| -r base-requirements.txt | |||
| -r prod-requirements.txt | |||
| django-polymorphic==3.0.0 | |||
There was a problem hiding this comment.
move to base-requirements before merge.
| FOUNDATION = "psf" | ||
| PYCON = "pycon" | ||
| PYPI = "pypi" | ||
| CORE_DEV = "core" |
There was a problem hiding this comment.
yes! i think this is a wonderful idea!
sponsors/models.py
Outdated
| @@ -819,3 +839,33 @@ def nullify(self, commit=True): | |||
| if commit: | |||
| self.sponsorship.save() | |||
| self.save() | |||
|
|
|||
|
|
|||
| class BenefitFeature(PolymorphicModel): | |||
There was a problem hiding this comment.
This seems like a suitable base name honestly. "Features" will include:
- Logo Placements
- Requirements
- Deadlines
- Notifications
So I think this is the best generic term we can really come up with!
…eatureConfiguration
…run within a transaction
|
@ewdurbin I think the DB modeling part of this work is done but I guess we have a problem with the build. It's failing due to this error: This error wasn't happening in my local env because I've installed the project with Since we talked this week about upgrading Django version to 2.2 LTS, I think this build error is a new evidence suggesting this. If you're ok with it, I can open a new PR addressing this. If you want to take a look, here are the backward incompatibilities list: Django 2.2 will be supported until April 2022, which give us enough room to safely schedule a Django 3.0 upgrade too. * can we also rename the |
| @@ -513,6 +530,13 @@ def new_copy(cls, benefit, **kwargs): | |||
| **kwargs, | |||
| ) | |||
|
|
|||
| # generate benefit features from benefit features configurations | |||
| for feature_config in benefit.features_config.all(): | |||
| feature = feature_config.get_benefit_feature(sponsor_benefit=sponsor_benefit) | |||
There was a problem hiding this comment.
I really appreciate that this is a method that can be defined! Will be super helpful in setting up things like "Deadlines" which may be dependent on the date of approval!
| """ | ||
| raise NotImplementedError | ||
|
|
||
| def get_benefit_feature(self, **kwargs): |
There was a problem hiding this comment.
For now this is 💯, but it may make sense to leave this as unimplemented and allow for each Configuration to make decisions, although of course they can be overridden in inheritance :)
@ewdurbin this is still a WIP, but I'm opening it so you can review how I implemented the DB modeling we've talked about recently. Besides that, this PR also enables PSF staff from adding features to an existing benefit vai Django's stack inline admin.
The process is pretty much intuitive:
The benefit feature can be afterwards edited and/or deleted, of course. Here are print screens to display the menu to pick the type of feature and an example of a sponsor placement at PSF's sponsor page:
menu
logo at sponsors page
I'm stuck to the "feature" naming because I couldn't thing about anything better. Help with naming or help texts is always an amazing support for non-english speakers =)