Skip to content

Conversation

@carlobeltrame
Copy link
Member

This is a bugfix for the following scenario:

  • Load the picasso
  • Open the activity detail of an activity
  • Change the activity's category to one with a different numbering style

Expected outcome: All displayed instances of the schedule entry show the schedule entry number change, and all schedule entries at all times have the correct up-to-date schedule entry number.

Actual outcome: The color of the edited schedule entry changes, but the schedule entry number on the top left remains unchanged. Also, when navigating back to the picasso, the schedule entry numbering of other schedule entries is outdated.

@carlobeltrame carlobeltrame requested a review from a team August 19, 2025 09:25
@pmattmann pmattmann requested a review from a team August 21, 2025 18:24
@BacLuc BacLuc added the deploy! Creates a feature branch deployment for this PR label Aug 23, 2025
@BacLuc BacLuc temporarily deployed to feature-branch August 23, 2025 11:13 — with GitHub Actions Inactive
@github-actions
Copy link

github-actions bot commented Aug 23, 2025

Feature branch deployment currently inactive.

If the PR is still open, you can add the deploy! label to this PR to trigger a feature branch deployment.

return scheduleEntry.period().scheduleEntries().$reload()
})
)
this.loadScheduleEntry()
Copy link
Contributor

Choose a reason for hiding this comment

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

is this really needed?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes. Since fcb536f we explicitly switched from a computed to local state + watcher for the scheduleEntry in this component. Reason was that this way it's more robust when deleting the schedule entry, see #4975 where this change was implemented.
I just tried again to remove this line, and the sidebar day picasso is updated, but in the main content card's title bar the numbering scheme is not updated.

async reloadAllScheduleEntriesInRelatedPeriods() {
await Promise.all(
this.activity.scheduleEntries().items.map((scheduleEntry) => {
return scheduleEntry.period().scheduleEntries().$reload()
Copy link
Contributor

Choose a reason for hiding this comment

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

Just as info:
Like this the scheduleEntries of a period might be loaded multiple times.
(hal-json-vuex catches this, but just as info)

Copy link
Member Author

Choose a reason for hiding this comment

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

Fixed in 61b88b9

This is a bugfix for the following scenario:
- Load the picasso
- Open the activity detail of an activity
- Change the activity's category to one with a different numbering style

Expected outcome: All displayed instances of the schedule entry show the
schedule entry number change, and all schedule entries at all times have
the correct up-to-date schedule entry number.

Actual outcome: The color of the edited schedule entry changes, but the
schedule entry number on the top left remains unchanged. Also, when
navigating back to the picasso, the schedule entry numbering of other
schedule entries is outdated.
@carlobeltrame carlobeltrame force-pushed the reload-schedule-entry-numbering branch from 1d84370 to 61b88b9 Compare August 23, 2025 15:52
@carlobeltrame carlobeltrame added this pull request to the merge queue Aug 23, 2025
Merged via the queue into ecamp:devel with commit 87958e6 Aug 23, 2025
30 checks passed
@carlobeltrame carlobeltrame deleted the reload-schedule-entry-numbering branch August 23, 2025 16:05
@BacLuc BacLuc mentioned this pull request Sep 2, 2025
@github-actions github-actions bot mentioned this pull request Sep 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

deploy! Creates a feature branch deployment for this PR

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants