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

Bug: Change in Server push rules not applied #9673

Open
1 task done
skalvaro opened this issue Apr 11, 2024 · 2 comments
Open
1 task done

Bug: Change in Server push rules not applied #9673

skalvaro opened this issue Apr 11, 2024 · 2 comments
Labels
needs triage This issue has been automatically labelled and needs further triage

Comments

@skalvaro
Copy link

Actual behavior

When changing the push rules on a remote server the change does not get applied.
We wanted to change the rules from a local tag to a tag of the Workflow taxonomy.
After performing the change at first it looks successful but it then seems to get reversed to the old filtering.

Tags involved were:

  • Old tag (local): workflow:state="released"
  • New tag (from Workflow taxonomy): workflow:state="release"

We checked that the tag we wanted to apply is enabled on the remote server with a call to /servers/getAvailableSyncFilteringRules and this is the case.

All changes were performed as a user with the 'admin' role.

We could not find anything in the error logs relating to this.

For now we solved it by manipulating the related server entry directly in the db but this is clearly not future proof.

Expected behavior

Change in push rules, or any other rules, in the 'Remote Servers' should be applied or at least have a log entry indicating what would be wrong (like a used tag not being present or enabled on the remote server).

Steps to reproduce

Make a change to the push rules on a 'Remote Server'.

Version

v2.4.188 (8ac96cc)

Operating System

Ubuntu

Operating System version

22.04

PHP version

7.4.33

Browser

No response

Browser version

No response

Relevant log output

No log output found related to this.

Extra attachments

image
Right after the update it seems to be applied.

image
After a browser refresh we see that it is reverted to the previous situation (the old tag was previously deleted, that's why you see the id of the old tag)

Code of Conduct

  • I agree to follow this project's Code of Conduct
@skalvaro skalvaro added the needs triage This issue has been automatically labelled and needs further triage label Apr 11, 2024
@skalvaro
Copy link
Author

To make it clear, this behaviour is the same whether the 'old tag' was deleted or not before trying to make the change.

@skalvaro
Copy link
Author

We just tested this on our UAT with version v2.4.189 (04100d1) and the same outcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs triage This issue has been automatically labelled and needs further triage
Projects
None yet
Development

No branches or pull requests

1 participant