Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[12.0][MIG] resource_multi_week_calendar #1389

Open
wants to merge 15 commits into
base: 12.0
Choose a base branch
from

Conversation

carmenbianca
Copy link
Member

A backport of #1384

Internal task: T12626

Signed-off-by: Carmen Bianca BAKKER <carmen@coopiteasy.be>
…calendar

This is the bones of the implementation.

Signed-off-by: Carmen Bianca BAKKER <carmen@coopiteasy.be>
Signed-off-by: Carmen Bianca BAKKER <carmen@coopiteasy.be>
…atch

This is the real implementation work. With this method implemented, all
other methods correctly get the correct week each time.

Signed-off-by: Carmen Bianca BAKKER <carmen@coopiteasy.be>
The epoch date is hidden on the child anyway. Let's just hide it, and
always make sure to get the parent's epoch date. This gets rid of the
complicated computation stuff that won't backport well to v12.

Signed-off-by: Carmen Bianca BAKKER <carmen@coopiteasy.be>
…s attendances

The idea here is that the children contain all the logic/attendances,
and the parent is just a holder of children.

Signed-off-by: Carmen Bianca BAKKER <carmen@coopiteasy.be>
Signed-off-by: Carmen Bianca BAKKER <carmen@coopiteasy.be>
Signed-off-by: Carmen Bianca BAKKER <carmen@coopiteasy.be>
Signed-off-by: Carmen Bianca BAKKER <carmen@coopiteasy.be>
@carmenbianca
Copy link
Member Author

@huguesdk Backport done.

I need this elsewhere. It _technically_ reduces performance by doing the
same calculation twice, but this module is horrible as pertains to
performance in any case.

Signed-off-by: Carmen Bianca BAKKER <carmen@coopiteasy.be>
@carmenbianca carmenbianca force-pushed the 12.0-mig-resource_multi_week_calendar branch from 698f076 to 50f0b0c Compare September 3, 2024 12:14
Copy link
Member Author

@carmenbianca carmenbianca left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unfinished review done with @huguesdk

resource_multi_week_calendar/models/resource_calendar.py Outdated Show resolved Hide resolved
resource_multi_week_calendar/models/resource_calendar.py Outdated Show resolved Hide resolved
resource_multi_week_calendar/models/resource_calendar.py Outdated Show resolved Hide resolved
resource_multi_week_calendar/models/resource_calendar.py Outdated Show resolved Hide resolved
resource_multi_week_calendar/models/resource_calendar.py Outdated Show resolved Hide resolved
- `parent_calendar_id` is now `ondelete="cascade"`.
- Renamed `family_calendar_ids` to `multi_week_calendar_ids`.
- Renamed `current_calendar_id` to `current_multi_week_calendar_id`.
- Renamed `_get_calendar` to `_get_multi_week_calendar`.

Signed-off-by: Carmen Bianca BAKKER <carmen@coopiteasy.be>
Signed-off-by: Carmen Bianca BAKKER <carmen@coopiteasy.be>
- Improved the comment on how week_sequence works.
- Renamed family_size to calendar_count
- Added a comment on _get_multi_week_calendar() returning a 1-item
  recordset.
- Re-optimised the current week calculation.

Signed-off-by: Carmen Bianca BAKKER <carmen@coopiteasy.be>
@carmenbianca carmenbianca force-pushed the 12.0-mig-resource_multi_week_calendar branch from 6766eea to 098a235 Compare September 9, 2024 12:45
@carmenbianca
Copy link
Member Author

Review with @huguesdk finished, all things addressed.

@carmenbianca carmenbianca force-pushed the 12.0-mig-resource_multi_week_calendar branch from 098a235 to c7a15cf Compare September 9, 2024 13:26
…ndar

Signed-off-by: Carmen Bianca BAKKER <carmen@coopiteasy.be>
Signed-off-by: Carmen Bianca BAKKER <carmen@coopiteasy.be>
@carmenbianca carmenbianca force-pushed the 12.0-mig-resource_multi_week_calendar branch from c7a15cf to 1d4db07 Compare September 9, 2024 13:55
Copy link

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.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.

@github-actions github-actions bot added the stale PR/Issue without recent activity, it'll be soon closed automatically. label Jan 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale PR/Issue without recent activity, it'll be soon closed automatically.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants