-
Notifications
You must be signed in to change notification settings - Fork 191
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
Add notification for users with disabled SCC data forwarding (jsc#SUMA-431) #9582
base: master
Are you sure you want to change the base?
Add notification for users with disabled SCC data forwarding (jsc#SUMA-431) #9582
Conversation
👋 Hello! Thanks for contributing to our project. If you are unsure the failing tests are related to your code, you can check the "reference jobs". These are jobs that run on a scheduled time with code from master. If they fail for the same reason as your build, it means the tests or the infrastructure are broken. If they do not fail, but yours do, it means it is related to your code. Reference tests: KNOWN ISSUES Sometimes the build can fail when pulling new jar files from download.opensuse.org . This is a known limitation. Given this happens rarely, when it does, all you need to do is rerun the test. Sorry for the inconvenience. For more tips on troubleshooting, see the troubleshooting guide. Happy hacking! |
Suggested tests to cover this Pull Request
|
44b2b20
to
7a90392
Compare
2406b37
to
781a516
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
I'm not sure if the new property should be add in last, as developed, or as the first to give more visibility.
@admd any comment on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Just one question: Do we also plan to show this checkbox for uyuni users?
Good question, Pascal. I'll leave this for @admd or perhaps @rjmateus to give a final answer. From my POV, while it doesn't seem strictly necessary for Uyuni, Uyuni users can currently change this property, so showing a notification for them shouldn't be an issue if applicable. |
Hi @wweellddeerr thank you for the implementation. Just a couple of questions without looking into the code, but overall looks good.
For Uyuni, we should show this warning only if SCC connection is there. I mean if Uyuni instance is connected to SCC, we should show this warning in case user has opted out. And yes, it's fine to show this checkbox to Uyuni users. |
@wweellddeerr please do not merge it without discussing it again. I will arrange a meeting to brainstorm it |
5993d69
781a516
to
5993d69
Compare
5993d69
to
bf0959c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thank you for this change Welder
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thank you Welder, this looks good.
else { | ||
ConfigureSatelliteCommand csc = CONFIG_ACTION.getCommand(user); | ||
csc.updateBoolean(ConfigDefaults.FORWARD_REGISTRATION, Boolean.TRUE); | ||
ValidatorError[] verrors = csc.storeConfiguration(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the change also reflected in the file(rhn.conf? )?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One more question. We are only changing the property here but if some user actually disabled the taskomatic job, we don't take care of enabling that here, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the change also reflected in the file(rhn.conf? )?
Yes, it does.
One more question. We are only changing the property here but if some user actually disabled the taskomatic job, we don't take care of enabling that here, right?
If the Taskomatic job is disabled, the user won’t receive the notification because it is created inside the job. We could create a different job specifically for the notification; however, it would still be possible for the user to disable this specific job. So, I don’t think it’s worth it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
About the taskomatic job: I think one thing that we could consider doing here is resetting the schedule to the default one (the one you have after installation), just in case someone might have changed it to only run once per month or so? Not a blocker for this PR though, if it turns out to be complex we can skip it for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I remember correctly we have a different problem. You cannot "disable" a job. In fact it is removed and you cannot get it back. I think we have a separate issue or bug report about it. This problem is bigger than just a changed schedule
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thank you for the pointer Michael, that one is concerning :(
java/conf/rhn_java.conf
Outdated
@@ -214,7 +214,7 @@ java.kiwi_os_image_building_enabled = true | |||
java.notifications_lifetime = 30 | |||
|
|||
# Configure the disablement of notification messages by type - example disabling all notification types | |||
#java.notifications_type_disabled = OnboardingFailed,ChannelSyncFailed,ChannelSyncFinished,CreateBootstrapRepoFailed,StateApplyFailed,UpdateAvailable,SubscriptionWarning | |||
#java.notifications_type_disabled = OnboardingFailed,ChannelSyncFailed,ChannelSyncFinished,CreateBootstrapRepoFailed,StateApplyFailed,UpdateAvailable,SubscriptionWarning,SCCOptOutWarning |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking back again, please remove this from example.
bf0959c
to
9296dff
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, this looks really good to me now! 👍
else { | ||
ConfigureSatelliteCommand csc = CONFIG_ACTION.getCommand(user); | ||
csc.updateBoolean(ConfigDefaults.FORWARD_REGISTRATION, Boolean.TRUE); | ||
ValidatorError[] verrors = csc.storeConfiguration(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
About the taskomatic job: I think one thing that we could consider doing here is resetting the schedule to the default one (the one you have after installation), just in case someone might have changed it to only run once per month or so? Not a blocker for this PR though, if it turns out to be complex we can skip it for now.
What does this PR change?
It adds the logic for creating a new notification every 3 months for users with disabled SCC data forwarding.
It also includes a new option for enabling SCC data forwarding configuration directly by clicking in the notification link.
GUI diff
Documentation
No documentation needed, the related warning in docs is already released.
DONE
Test coverage
ℹ️ If a major new functionality is added, it is strongly recommended that tests for the new functionality are added to the Cucumber test suite
No tests: add explanation
No tests: already covered
Unit tests were added
Cucumber tests were added
DONE
Links
Issue(s): https://github.com/SUSE/spacewalk/issues/25778
Port(s): https://github.com/SUSE/spacewalk/pull/26072 https://github.com/SUSE/spacewalk/pull/26073
Changelogs
Make sure the changelogs entries you are adding are compliant with https://github.com/uyuni-project/uyuni/wiki/Contributing#changelogs and https://github.com/uyuni-project/uyuni/wiki/Contributing#uyuni-projectuyuni-repository
If you don't need a changelog check, please mark this checkbox:
If you uncheck the checkbox after the PR is created, you will need to re-run
changelog_test
(see below)Re-run a test
If you need to re-run a test, please mark the related checkbox, it will be unchecked automatically once it has re-run:
Before you merge
Check How to branch and merge properly!