Refactor label rule change

Issue description

Currently a change in the php code of a label rule is treated just like a change of the instances of the respective topic type, so a topic touch. But this makes it impossible to give the administrator immediate feedback if there is a runtime error during label rule computation on a change like it is the case when changing a computation rule.

Developer comments

Given a topic type TT1 with a label rule LR1. Let S1 be the set of all instances of TT1. In the [https://www.topincs.com/topincs/meta/906, trigger] for each store language the following should happen: * Compute the set of topics for which the label depends on S1 (=S2) * Delete the labels of S1 * Compute the new labels of S1 * Label touch all dependent topics S2 When the save process ends, topic touch will update the labels of S2.

I am reconsidering this for several reasons: * The change would be a lot of work and it is unclear whether it would be really better afterwards. * The current approach has been in place for many years and works well. The computation rule approach (immediate feedback on runtime error during saving) works better, but the situation is different. A computations rule is a *single* PHP code fragment. A label rule can be several, but also up to a dozen in a multilingual store.

Rejection comment

Too much work with uncertain return.

Reporting date

2025-04-04

Reported by

Robert Cerny

Rejection date

2025-04-07

Rejected by

Robert Cerny

Related to

Avoid flood of emails when error in label rule(Change)

Work sessions2

Start	2025-04-04T15:31:03
End	2025-04-04T16:48:11
Participant	Robert Cerny

Start	2025-04-06T14:42:00
End	2025-04-06T16:36:00
Participant	Robert Cerny