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

Fixes #20264: Allow to customize in which menu plugins are set #3993

Conversation

VinceMacBuche
Copy link
Member

@VinceMacBuche
Copy link
Member Author

Commit modified

@VinceMacBuche VinceMacBuche force-pushed the ust_20264/allow_to_customize_in_which_menu_plugins_are_set branch from 55252d2 to 9de4c53 Compare November 17, 2021 09:28
@@ -356,28 +356,28 @@ class Boot extends Loggable {

// All the following is related to the sitemap
val nodeManagerMenu =
(Menu("NodeManagerHome", <i class="fa fa-sitemap"></i> ++ <span>Node management</span>: NodeSeq) /
(Menu("10", <i class="fa fa-sitemap"></i> ++ <span>Node management</span>: NodeSeq) /
Copy link
Member

Choose a reason for hiding this comment

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

I think we should keep the number only as a prefix, like what you did for plugin below, because:

  • it will make debugging in some cases easier (IIRC, we have a map of menu id -> menu at some places, and having only "10" won't help much)
  • having globally unique name is less risky if at some point we make a map of all menu items (including sub menu).

Copy link
Member

Choose a reason for hiding this comment

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

these name will become part of the api (since they can be used by plugin), we need to normalize them, I propose:

  • two digits followed by -
  • lower case, no space, - between words

Copy link
Member

Choose a reason for hiding this comment

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

OK, using a name is perhaps not super futur proof, because it will be hard to rename that id. I'm not sur it is of importance (we can still rename between major version, since plugin are not compatible between them).

"secure" / (name+"Manager") / "ruleManagement"
>> LocGroup(name+"Group")
>> TestAccess( () => userIsAllowed("/secure/index",AuthorizationType.Rule.Read ) )

, Menu("Rule Details", <span>Rule</span>) /
, Menu("10", <span>Rule</span>) /
Copy link
Member

Choose a reason for hiding this comment

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

I don't think we should authorize same menu idea, I'm pretty sure it will create unspecified behavior

Copy link
Member

Choose a reason for hiding this comment

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

(even for hidden menu)

"secure" / "utilities" / "healthcheck"
>> LocGroup("utilitiesGroup")
>> TestAccess ( () => userIsAllowed("/secure/index",AuthorizationType.Administration.Read) )
)
}

val rootMenu = List(
Menu("Dashboard", <i class="fa fa-dashboard"></i> ++ <span>Dashboard</span>: NodeSeq) / "secure" / "index"
Menu("0", <i class="fa fa-dashboard"></i> ++ <span>Dashboard</span>: NodeSeq) / "secure" / "index"
Copy link
Member

Choose a reason for hiding this comment

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

use 00 here, for consistancy

"secure" / "administration" / "apiManagement"
>> LocGroup("administrationGroup")
>> TestAccess ( () => userIsAllowed("/secure/administration/policyServerManagement",AuthorizationType.Administration.Write) )
)

def pluginsMenu = {
(Menu("PluginsHome", <i class="fa fa-puzzle-piece"></i> ++ <span>Plugins</span> ++ <span data-lift="PluginExpirationInfo.renderIcon"></span>: NodeSeq) /
(Menu("50 - plugins", <i class="fa fa-puzzle-piece"></i> ++ <span>Plugins</span> ++ <span data-lift="PluginExpirationInfo.renderIcon"></span>: NodeSeq) /
Copy link
Member

Choose a reason for hiding this comment

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

you should not use that with the toIntOption. But I'm not sure we should convert to int at all.

"secure" / "plugins" / "index"
>> LocGroup("pluginsGroup")
>> TestAccess ( () => userIsAllowed("/secure/index", AuthorizationType.Administration.Read)
)) submenus (
Menu("pluginInformation", <span>Plugin information</span>) /
Menu("0", <span>Plugin information</span>) /
Copy link
Member

Choose a reason for hiding this comment

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

I think I would use 01 here to let the possibility to have things before in the future, in the middle of a release cycle.

val menu = if (menus.exists (_.loc.name == name )) {
menus
} else {
(parentMenu :: menus).sortBy(_.loc.name.toIntOption.getOrElse(Int.MaxValue))
Copy link
Member

Choose a reason for hiding this comment

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

I think you can use the same logic without the toInt

@VinceMacBuche VinceMacBuche force-pushed the ust_20264/allow_to_customize_in_which_menu_plugins_are_set branch from 9de4c53 to fc06b00 Compare November 17, 2021 22:16
@VinceMacBuche
Copy link
Member Author

Commit modified

@VinceMacBuche
Copy link
Member Author

Commit modified

@VinceMacBuche VinceMacBuche force-pushed the ust_20264/allow_to_customize_in_which_menu_plugins_are_set branch from fc06b00 to 6ed61e4 Compare November 18, 2021 11:38
@Normation-Quality-Assistant
Copy link
Contributor

This PR is not mergeable to upper versions.
Since it is "Ready for merge" you must merge it by yourself using the following command:
rudder-dev merge https://github.com/Normation/rudder/pull/3993
-- Your faithful QA
Kant merge: "Live your life as though your every act were to become a universal law."
(https://ci.normation.com/jenkins/job/merge-accepted-pr/47031/console)

@fanf
Copy link
Member

fanf commented Nov 18, 2021

OK, merging this PR

@fanf fanf merged commit 5dd27ed into Normation:branches/rudder/7.0 Nov 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants