[16.0][REF/ADD] Create membership_type, membership_custom_date #161
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
carmenbianca
force-pushed
the
16.0-membership_type
branch
2 times, most recently
from
8778c5b
to
6ea6037
Compare
carmenbianca
changed the title
carmenbianca
force-pushed
the
16.0-membership_type
branch
5 times, most recently
from
3078281
to
f760603
Compare
carmenbianca
commented
Nov 27, 2023
carmenbianca
force-pushed
the
16.0-membership_type
branch
from
f760603
to
92e9f50
Compare
nayatec
suggested changes
Jan 23, 2024
Make membership_variable_period depend on it. This allows future modules that also use the membership_type field. Signed-off-by: Carmen Bianca BAKKER <[email protected]>
This module is needed for memberships that have a custom date range for every individual. The normal workflow when clicking on 'Buy Membership' does not involve specifying the start and end dates. Rather, those dates are calculated from the membership product. This calculation happens _after_ clicking on 'Invoice Membership' in the wizard UI. If we want to include the dates in the wizard UI, we disrupt this workflow, and override the default behaviour of using the dates configured in the membership product. We circumvent this by only breaking the workflow for membership products of type 'custom', which would be expected. We keep the workflow for other types. An alternative method is to calculate the dates from the product selected in the wizard (onchange), but this is UX-wise incompatible with the a downstream (non-OCA) requirement that the dates be changed to the dates specified on another model (also onchange). So depending on which field you changed last (product or other model); that's the dates you get. This is strange and unexpected behaviour. Signed-off-by: Carmen Bianca BAKKER <[email protected]>
…from and date_to on membership line This was a bit tricky to get right, architecturally, but I think I arrived at the correct design decision. On the whole, the new restriction makes sense. Following from the fact that dates are mandatory on 'fixed dates' (read: default) membership products, and following from the fact that dates are always set on the membership lines of 'variable period' membership products, membership lines should _always_ have values for date_from and date_to. The fact that these fields are not already required is a strange design decision. The constraint in membership_extension _effectively_ sets required=True on these fields. However, there is a use-case for memberships that do not have an end date (using the 'custom' membership product). For those scenarios, we add a toggle on the product (exclusive to 'custom' products) on whether to apply the constraint. Signed-off-by: Carmen Bianca BAKKER <[email protected]>
carmenbianca
force-pushed
the
16.0-membership_type
branch
from
92e9f50
to
1239790
Compare
nayatec
approved these changes
Jan 29, 2024
|
There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. |
github-actions
bot
added
the
stale
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
membership_custom_dateis a custom module used by Akretion/UGESS. It used to depend directly onmembership_variable_period, which functionally made no sense, but was necessary because we re-used themembership_typefield on product.template.I've factored out that field into
membership_typeand made bothmembership_variable_periodandmembership_custom_datedepend on that new module.(Almost) no history was lost for
membership_custom_datein copying the module over. 99% of the code was already in a single commit.