 Welcome. This is the Jenkins User Experience Special Interest Group. It's May 25th, 2022. Let's get the attendee list here correct. Thanks for joining. Topics I had on the agenda for today include, oh good, Jan's here, excellent. So I had preparing for June LTS as one topic to see if there were additional changes we need to discuss here that should be backported. UI improvements, Jan and Tim wanted to allow time here, particularly Tim if you wanted to highlight the new login screen or any other topics. And I had included a topic for localization and crowd in enterprise if we've got time. Any other topics that need to be added to the agenda. Okay, great. And then, then for me the first topic was prepping for the June LTS there are some, some things that were mentioned or are open as pull request to Jenkins core that Tim I wanted to use as a chance to check with you and with young to see if there are things where you say, hey this should be backported or that should be. For example, there was this Java 17, there were a couple of Java 17 related things. Is it okay if those wait till dot two or dot three. They're not really UI related so I guess maybe I'm out of out of order asking here but to the Java 17. Yeah, I don't think the Java 17 one needs backporting. Okay, good. But I wouldn't rush to backport them. Right, give it a few weeks to bake in weekly. Good. Okay. Now there was this one on the inbound cookie key for for a specific one for remoting. Yeah, it seems like Vincent is trying to get that get up. I think he can request it if he wants to be in dot one. Otherwise, it'll go on to dot two issue. Okay. All right. And then on the closed list, this open search to use the newer Jenkins logo actually seemed safe to me but I wasn't sure if it's important enough to consider a backboard. No one's noticed in 10 years. Ah, good. Okay, other than other than yeah. Got it. Okay. All right. So, so and this one I think the new layout for remote class loader stats was already backported if I remember right. No maybe not this one was not but it's and again it's it could wait till dot two. It's a feature sort of one that wouldn't normally backport it we might bring into a dot one, but we probably wouldn't. I guess it's kind of out of sync with the rest of the UI, but Yeah, but quite relatively harmless right yes it's out of sync but it's it's certainly not a functional functional damage thing. It's probably class as a bug by not matching the rest of the UI. Right. So if you want to backport I would change it to be a bug. Otherwise it won't shop and any filters. Oh, all right. Okay. All right. Good thank you so we'll just follow the following the usual process for backports to propose backwards and make them happen. Great. Any other guidance you want to give their Tim on prepping for the June LTS. No, I think we're good. Good. All right and my my interactive testing with the release candidate has been really positive. Next topic then UI improvements young or Tim are there any topics you would like to bring here there for discussion. I've got the one. keyboard shortcuts on Jenkins. That would be cool. Are you okay sharing sharing your screen or is there something you'd like to show for discussion. Yeah, I can share my screen effects. All right. All right, so let me stop. Sweet. All right. It's just a small thing that I've been toying with. You guys see my screen. Awesome. Okay. And so the whole idea is just to kind of improve navigation around Jenkins. And with the use of keyboard shortcuts and save we go to open up a project, you'll now see that certain actions have little keys assigned to them. And so you can press these keys on the keyboard to actually activate those. So if you press w post your workspace, press B to build a job. Press S to go to the configure screen. Just works like that. If we open up an actual build, you can press C to quickly go to your console, or you can press J or K to flick between different builds. So via J goes to the previous build, hit K. Goes to the next. If you press command K. It'll focus the search bar so you can instantly start typing. Hello world. You can instantly start doing that. So you have to move your cursor. And there's also a handy little dialogue you can open to see the available keyboard shortcuts for a page. So if you hit keyboard shortcuts in the photo, you'll get this small little model will just explain the different keyboard shortcuts are available to you. Kind of interact with them whilst this dialogue is open about actually interviewing the page so you can try them out without doing any damage. So if I press command K, you'll notice the search kind of option highlights. Press C console does it then J or question mark to the keyboard shortcut dialogue. So it's a really simple look at it really. There's not a whole lot to it right now. Just for an exploration into how keyboard shortcuts could work on Jenkins and it's actually any benefit. So I don't have any questions or anything. Okay, how do, how do we, how do we referee or control who adds which shortcut so be feels like a great shortcut for build now but I happen to be named Bob and I think Bob should be the preferred shortcut and I'm going to create a plug in the Bob. No, sorry bad example but you probably get my idea. Yeah. There's nothing right now in the kind of prototype to stop that. But ideally would have some sort of exception for if you try to kind of override a call Jenkins keyboard shortcut. All the way they're implemented right now is that just data attributes. So you can see that, but for the build now option that just has a data keyboard shortcut be. And also has a shortcut title as well which displays on the dialogue that opens. So it's really easy to touch the implement in a plug or anything, but nothing to actually stop overriding anything just yet. But if you want to go through with this then that would be pretty quite straightforward to add. So, so this feels like you're making it much easier for me now to to interact with single key key actions, somewhat similar to how I use a slash to search GitHub. That's that's sort of the idea right it's it gives me that looks for any, any problems you've encountered or things where you saw Oh hey this is a risk for this area that okay the search dialogue for instance is is far from far from the capabilities that I would dream we had there. You know it's it's not quite doing all the things we'd want, but are there other things that you've seen Oh here potential struggles or challenges with it. Nothing too crazy. Say for example about this shared components, if you had a keyboard truck to a shared component that keyboard truck applies to everywhere that components used. It would kind of cause issues if you're not careful without your planet. For example, I wanted to show that that would take you to the most recent build of a project. So I applied it to this little button here thinking that being a straightforward place to add it. But on the homepage that components were used so that kind of interfere with the homepage then. And care does need to be taken to make sure that we're not kind of making kind of too many shortcuts for example but nothing, nothing too crazy running. So the, so the, the component reuse point that you made then is that, if, if I define a keyboard shortcut, it's available anywhere that component is used that defines the shortcut and in this case, top level page would have potentially many, many entries many rows, each one that has the same exact shortcut defined, taking me to the console of that thing and that that would, I assume give unexpected results. Yeah. So just four points I have concerning that approach. So first one, thank you for the proposal in terms of accessibility user experience for poor user it seemed to be a very nice approach. I will say the drawback is that we will have to increase the performance of Jenkins to suit this kind of feature we are proposing to the user but that's the more interesting aspect. If you have any questions concerning this feature, could you just open one page with the shortcut being visible with the keystrokes. Yeah, if you move the cursor on top of the w for example, are you seeing a title. Okay, so my first guess there is that we are getting a lot of questions, what are these kind of icon for people that are not used to have such keyboard being displayed It could be interesting to have a title to say hey it's a shortcut to do this kind of thing. See the dog or anything that is just useful for the final user. Second point, is it possible and the moment or do you plan to do it to disable completely the future. My gut feeling with what I have seen in the past is that this kind of feature is very good most of the time, except for some pages where the JavaScript is perhaps a bit not really good practice following good practices and interacting with expected features. For example, if you're starting to write something in the search bar and the JavaScript is perhaps not written correctly, your keystroke inside the search bar could trigger some shortcut. That happened to me in a lot of application and that was a bit painful. So is there a possibility to disable that behavior completely. And I will say as a last question, due to the question from Mark in terms of extensibility there, what do you plan to do if two plugins are proposing the same shortcut. Sure. So that first one was really good about the kind of tool tip or title showing. It could totally be confusing if you're not sure what these little keys mean. So that's really awesome. So I can definitely add like a tool tip or something more. You can just even remove them and relied on the modal could be an option. Not too sure what the best kind of approaches right now but it's definitely worth exploring. And as for say you're typing in the search bar, and you press one of the keys that are kind of assigned to say sidebar item for example, and the library we're using for this disables the keyboard shortcuts if you're entering input. That's not an issue. Thankfully, I will say when you know what you are doing, and there was a lot of plug in where the people does not really know what they were doing. I'm just afraid of this kind of possibilities in terms of regression. And then for the last point. I think we're going to need some sort of, maybe a lot of system in the console, for example, to kind of flag if a shock that's been kind of overwritten or if it's being used twice. You certainly won't want to press a button have two different things happen. That'd be pretty horrific. So something that could flag, say a platform developer before they try to release it would be really, really helpful. And perhaps as a first iteration, do not even try to put such shortcut for the dangerous action. For example, the delete project is kind of think, I will say it's already too easy for people to click on this kind of thing before desiring to click there. So just a good feeling. Now, now to sort of as a counter though to vatic your point, we already have symbol annotations that have the risk that users care that a plug in a maintainer can just like Mark weight made the mistake of doing can define a symbol get that in fact it's a pipeline step get and is not a good thing. So, so, so this collision thing we've already got but I think it's it's worth if there are ways to avoid hitting the collisions or warn people about a collision that's that's certainly healthy. Yeah, especially because there are not a lot of letters or keyboard that you can use compel to full symbols. And also in Jenkins we have something that is a bit particular. Some action could be displayed depending of some condition depending of some context or it's even more difficult for some plug in maintainer to know if they're creating something in conflict or not. Thank you, Jan. Thanks very much. I'll stop trying if that's all right. Okay, anything else that you wanted to share on that topic again. I'm nothing on that topic. You did mention kind of updating the search feature. And I gave a demo on that kind of a few months ago now. Back on one of the way back in the day meetings. I've kind of picked that up again. And process kind of reworking it looking a bit kind of easy to maintain. Which feature was that sorry. You know the kind of search modal. Oh yeah yeah search of the input would have a kind of modal pop up and you could kind of search on the screen. And basically extending that to be more like a command palette. You'd find in kind of visual studio code or something like that. It's really easy to find different options on Jenkins. But hopefully have something to download on that maybe next time. If I can get a bit more fleshed out. That's everything. Excellent. Thank you. Thanks very very much. So on that theme if if everybody if others would be okay with it I wanted to bring a specific topic up that sort of I think relates to what Jan was just saying it's this German language edition of an accessibility assessment. Would you be okay if I bring that to the to the group now out of sort of out of order. Objections good. So I was contacted by a person from I believe check the Czech Republic, or from Croatia, I forget exactly where. But what they were suggesting was hey they did this 60 page assessment of Jenkins accessibility as part of a company requested company purchase thing from some someone and they, they asked us hey are you interested in this report. And how is the best way to bring this report to the Jenkins project if you are interested. It's right now German language, it's right now private to them. So it's, it's not a public document yet but they've offered to translate it to English, and to be available now my question to, to the exig was, is that of interest, and how would what would be the most approachable if it is of interest to bring that report for for discussion and consideration. Yeah, how have you handled those kinds of things before Tim likewise and Basel I think you're the three most experience in these sort of spaces I'd be interested. What would work well or poorly for you. An issue like an issue on issues touching us I owe with it attached should be the start and then someone to review it and create issues in an epic out of it. If there's anything that looks like it's worth doing. If we started with attached the master PDF file to an epic in Jira and then create sub items as we as we need to as we feel to, based on those because none of these things are a commitment in any way they're all hey what can we do. We don't have interest, etc, but you would be okay if we put an archive or copy of that PDF on that top level epic and then used issues in Jira to report record things or if someone said hey I'm going to I'm going to try to improve this. They create an issue based on that report and record it there that would be okay. That's a good place to start. And there's probably a lot of low hanging fruit that we could find in that report. I imagine some things will be easy to fix and others might be bigger projects. But if there's things that are easy then it would be good to make no bite sized tasks in Jira, and we could even advertise those as part of you know future hackathons or contribute thongs. If there are simple things that could be fixed in a short amount of time it would provide some accessibility value then that could be a good opportunity to advertise those broader audience. I'd be happy to work on I'd be happy to try to work on splitting some of those issues up into Jira projects. Alright, thank you. Okay, so I'll I'll talk with them. Talk with them see if I can persuade them I think they've actually shared the German language document with me, and I've stated that they're willing for it to be made public. But let me double check with them. And if so then I'll likely upload the German language document and and see if they're willing to translate if they're not willing to translate. So they have the option of using the German language document as as it exists. Great, thank you. Alright, so that that covered that topic. Tim, did you want to do anything additional you want to highlight the new login screen or anything like that. Are there any other things on UI that you wanted to talk to. I'm not doing a quick review of the open progress but you could just you could just quickly share your screen on weekly.ci.jinkans.io. Okay, let me do the login screen. You bet here we go so sharing my screen. And you should now see the meeting notes and if I just go to weekly and click login. So the inputs are consistent with the rest of Jenkins now checkboxes actually have a focus state previously they didn't have a focus state but it wasn't really noticed because you had to tab off past the sign in button. And there's no sign up enabled on this instance but similar sort of things applied to the sign up page. The main reason of doing this was there was a pull request open to year or two back, which wanted to move to keep me signed in box to after the password input. But it was quite misaligned it was kind of not even was kind of indented a whole bunch randomly. So that was the reason to do that but then I found that the focus state didn't work and it was another issue. It was just a lot more consistent with the rest of Jenkins ago also. I think that code now was was completely isolated before but it's now pulling in the less files for the components or the components that we're using are imported in those files rather than copy pasting of CSS and using different CSS. So should be a lot easier to manage these pages going forward. So this is much less of a one off as a page than it was before and it looks the same as as other fields that are in Jenkins now for this upcoming LTS. Great for a week. There might still be a little bit of CSS but I deleted a lot of CSS and imported the existing components. Excellent. Thank you. To remind others weekly dot Jenkins dot ci dot Jenkins that IO continues to be updated. Yes, it's now running to that 349 was released on Tuesday and the design library is here and gives you a great chance to look at and see how, how, how you can do implementations of UI components in modernizing. So thanks very much Tim thanks young thank you thank you. We're working on a extension points in the theme manager at the moment to allow other plugins to contribute theming configuration to one area. So you don't have to have each plugin having its own theming section and then adding looking at adding a properties map to that where each theme can set the recommended theme. This is going to be for that plugin, which is going to be for the prism API prism API plugin which is a source code highlighter JavaScript and CSS library. I've got a pull request on the design library plug in which see integrates with prism API but it's not the best user experience. The user has to go and manually set their things theme and their configuration and like we never work on that weekly dot ci dot Jenkins.io. The theme should suggest the default theme and changes from default to theme matches matches theme or something. And yeah, and they're probably split the prism API plugin because it's got dependencies on the bootstrap plug in and the plugin util API and something else seems a bit heavy for what it is, even if they're kind of already installed everywhere. But yeah. It's because we also want to use this in the configurations code plugin, which is very dependency lights and even if those dependencies kind of find it'd be nice not to include them. But yeah, so that should be coming and so we're using the dark theme will not only be blinded with the code blocks and yeah and tried to hack that into the plugin as well. Just with some CSS server rides but hopefully we won't need those. Excellent. And now theme ability, the symbols that we're using now in the UI so they they have the benefit that they are themeable so they, they when I switched to dark theme, they don't become invisible right they really are usable and still ready to go. Excellent. Yeah, I think we just got the dark theme doesn't seem to be set on that weekly but we can probably hold off sitting out until card blocks react properly. All right. Anything else you wanted to highlight there. Just check how we are on the poor requests. Oh right you had suggested that just a minute let me get. Let's open up this. So this is Jenkins core pull request right. So got sex open at the moment. And so you were looking at Web UI. Yeah. Yeah, let's make it so I can read it with my bad eyes great. So, we're kind of stuck on the tipy one until matrix off. Actually, is Adrian here Adrian you're here. Did you see some of the tipy one if you go down to the bottom mark. You having an issue when you tested it do you know if you tested it with the poor request that adapts that makes it compatible. No, I tried on the other on installing the plugin I need to yeah I will I will check that sorry I didn't see your message before this meeting. I'll make sure to test with the appropriate build of the metric of. Yeah, that should fix it. I've applied the same fix on to these your ad plugin as well and that's released already. But having trouble getting hold of Daniel pinging for the last few weeks. If anyone wants to pass along the message. Yeah, sure. So what what's needed here is that one needs to be needs to be merged and released. Yeah, and one of the problem we have is that there's no easy way to override plugins and acceptance test harness doesn't increment it doesn't integrate with incrementals at all. I think we could add some hacky code with the current setup we could add some hacky code to the Jenkins file to download the plugins and put them in a specific directory. But it's not very nice. So we'd either need to come up with a more generic handling of it. Well currently we've kind of just been waiting for that to be released. But it's kind of annoying is we don't really have a way of testing the impact of a plug and change it in the acceptance test harness. We can handle core changes very easily but we can't really handle plug and changes. We can run it by like running the whole suite someone can locally run it and do what they need to but as that's a problem at the moment because a lot of plugins depend on matrix or and because the matrix and the matrix or part of ATH is failing and that causes a lot of tests to fail so we don't know if those tests are impacted until this is released. Okay, and now this this change, I assume it's it's still compatible with the pre tippy world. It's completely compatible. It's got to multiple levels of compatibility because changed in like 2.235 to 2.335 and praise or yeah, so I think when checkbox has changed all these levels of compatibility. Okay. And but yeah so that's what's holding that one up. Yeah, that's one's quite a good one because I think it should fix cross site scripting issues like generically across tooltips anyway. It removes the problem by not executing HTML in the default attribute you have to supply your own attributes after explicitly opt into it. So rather than the default it's an opt in behavior to be able to supply HTML. And now will that that change alter things like the markdown plugin that I use for instance I assume it won't be only a tooltips. Oh right sorry I'm, I should learn to read yeah tooltip specific and so the thing I'm doing is not tooltips maybe the badge plugin might be touched then because I think it does to tooltips okay thanks. Yeah, so the, I think the only was very very little places use HTML and that we've allowed us to some very common ones which are BR basically quite a few places use BR to create a new line. We've allowed that sort of, apart from that the only other place I found so far is the matrix author uses a strong tag tag to make some text bold. And that's pretty much about it I think I'm not sure. Yeah. Excellent. Thank you. Anything you want to review on other other of these web UI pull requests that are pending. So just going through them. I was just going to give a quick update. So the tango one Alex well like or anyone. There's some unit tests failing with it just needs someone to look at the unit tests. It's really vulnerable because they generally rely on some sort of image and the image gets removed or changed or gets bought to be an SVG from an image and these tests these sort of tests fail all the time. Okay. Thanks. The next one's configure project. I think. I can't remember what's wrong with that should be a comment on it though. PCT. So bomb tests are failing in a few plugins not very many. Well some weird undefined era when it's trying to add the event selected but I like it's hard to tell because I think it only gives the line number of one but it looks like it's saying basically window is undefined because it's literally accessing window. As far as I know. I tried running the plugin tests locally with without PCT and it seemed fine. I created a mega war and then I ran out of time to try and reproduce it actually in PCT and try and debug interactively, but it's from looking at it so far. It seems really weird and maybe HTML units being stupid I don't know. Okay, so, so and now this workflow job plugin that needs a release. Has that actually been released in the check box. Don't know it might have been merged yesterday so possibly now. I think it was released yesterday. Okay, yeah, because I believe this plugin is doing continuous delivery right. Yeah, so it's probably delivered. Okay, great. I'll update that. Yeah, so it's just the PCT whether any more action items for the changes to adapt the folders plugin and work and the workflow job plugin to display the new UI features because we had some pull requests for those that are not. They're not blocking this change but they're related to it in that they would they would allow other plugins to use this new feature. So the forward compatibility is fixed and for folders that I think that PR has been reviewed and tested and it's ready for when the core is released. It's not very easy to make it for compatible to be a lot. There's a lot of changes in the markup. Right, so great. So that's really all I was asking was whether there's any additional action items for those and it sounds like it's not like we just need to wait for core to be released and for the plugin maintainer to be willing to adjust the baseline and then those other two can be released sounds great. Yeah. Yeah, and yeah, once that ones and I want to change the configure cloud pages to use the same design, because I hate that page. It's so hard to find stuff it gets so big. And I've wanted something like this for a long time. Great. So anything that you want to review on other topics here Tim. I think we I think. So the next one HHH tests are failing. So I think I think some HHH tests have started failing. So I need to check. We need to fix them and get them passing again. And it kind of comes back to Basil's some of the HHH stuff from the mailing list. But yeah, I would be good to have a way that it doesn't randomly break. Yeah, so this is so you're saying this is the one you're describing right where. No, it's the one I was talking about with fixed spacing and job conflict page. So PR looks good and straightforward. There is something like 12 tests failing and so I need to check if the legitimate failures and the and well either way they need fixing. We don't really want to be making judgment calls because as has happened previously they are just shadowing. So when those tests were fixed, they actually failed later on. So I don't really want to be accepting things with the test failing that effect it. Right, right. Okay, so this is the one where the before has this gap here between GitHub project and pipeline speed durability and the after gets rid of that that gap so that it looks consistent. Yeah. Got it. Okay, thank you. Yeah. And the form validation one has got changes of function or moves of function or something which a few plugins relying on. Okay. Get parameter plugin we had some of probably had some of the problems we have problems with that during tables to do as well as doing some weird stuff for form validation I think. Yeah, get parameter plugin is also bundling an outdated jQuery that we would love to get rid of so they're the get parameter plugin has a number of challenges. Did you get a chance to look at that young. I've not had a proper look yet. I didn't run it but I couldn't get the exception to occur. And it was on this post, but it's definitely using some custom validation objects that we get to kind of remove if possible but I'm not really sure what it's doing at the moment. Okay, so that what you're referring to young is described here in turn in the comments. Yeah. Great. All right, thank you. Okay. Excellent. Anything else on on the open poll request for web UI. No, I think that's it. Okay. All right. So, other one question for you young I guess is, how, how do you get on with the like with a replacement icons be quite good to get those and at some point. They're still similar branch, the way I went about it was a bit of a kind of refactor of how the ball kind of component worked. So after the kind of symbol pure went in that kind of broke a few areas is a bit kind of hesitant to kind of open it. Definitely kind of bring it up to date with master and see what it's like now. Or we could alternatively just do about the refactor and just replace the symbols in the SVG if that makes sense directly. Yeah, whatever makes sense I guess. It would be nice to have the kind of weather icons accessible as Jenkins symbols. Yeah, that would be good. So, so to be sure I understand that's, let's go back to weekly so the weather icons, oh they're probably, oh there is a job here okay so this is a weather icon right and that is not currently done as a symbol. No, that's, it's a weird kind of, we used to have a ball back in the day and there's a whole component based around it and it's all kind of hierarchy. It's a bit weird. So I looked at replacing that to make it a bit simpler, and also integrated with the new symbols we've got. But just a bit hesitant if any problem to use that and what I don't want to break anything touch what. All right. Okay, any other topics there. What I had was localization and crowd and enterprise. Just to give thanks to Alex Brown does who's been doing wonderful things with crowd in Jenkins.io thanks to crowd and enterprise for donating the license and thanks to translators like Bruno and Alex and Chris Stern, we've got translations. So right now we've got is it seven or eight different plugins that are working through here. And we hope soon to do some highlights on how you internationalize Jenkins plugins to encourage more of this sort of work. Yeah, it's really, hopefully, hopefully it becomes really useful. But yeah, I think it's, as I mentioned on the main list to be really good to revive one of those translation assistance plugins and localization plugin and kind of link into here maybe. Right. Yeah, so if, if we could find a way to well so for instance to jump into something that shows the string native language from inside the Jenkins UI and encourages people hey contributed translation here. Yeah, I think that that that feels like a really, a really great idea. Yeah I think that existing plugin has 25,000 installations or something around that order. You know updating it and releasing a new version would essentially expose 10s of 1000s of people to this new crowd and website, which is a lot more people than you could expose then just by advertising on a few mailing lists. Right. I think that could be a powerful way of funneling contributions in. Yeah. And if we want even more than that we could even install it by default in the suggested plugins list. I wouldn't be opposed to that either. And then that would that would escalate the funnel to maybe 200,000 instead of 25,000. Good insight thank you. If you have other items on localization and crowd in, then I've got one more item that I wanted to add to the agenda just to ask for advice, and I, this is piracy of the agenda. But I wanted to ask about a UI thing that I'm considering doing to one of my plugins but I wanted young and Tim while you're here to guide me on this so I've got a plugin that I maintain called job priorities it puts itself over here on the left hand sidebar. I don't think it helps users being there. Are there reasons why I should not move that into manage Jenkins so that it's somehow we're in here. Are there is there damage that I do if I attempt that kind of a move just like I don't find lockable resources particularly useful here. Is there a reason we should not move those into manage Jenkins or someplace else. One avoid sidebar links if you can they just take up space, they make you scroll down and, and then a lot of them aren't used very much to. Sometimes they're there if non privileged users need to need to use them. But you can also change that so that privileged users see it on the manage Jenkins page and non privileged users there. Another thing is, I tried to expose the manage Jenkins page to more users but kind of got blocked by Daniel. Thinking that existing initiatives will get very scared of other people started seeing that, but I was kind of trying to make it so that people would see credentials there and see and see a lie and sort of thing. So the smaller tasks that less privileged users, they just exposed that page up a bit more. But yeah, especially if I don't know who can change job priorities at the moment. Me. Like, as a, as a user of Jenkins, who can, who has permission to manage job priorities. There's a facility that allows non admin users to modify it, but I like your idea that I could hide it on the admin page for admin users, and only put it on the sidebar for, for non admin users. That already gives me hope. So the credentials plugin as an example of that so it does that. Good. So I can look at somebody else's code. Good. All right, thank you. So, so for me similarly lockable resources now I don't, I'm not a maintainer of lockable resources but lockable resources has, has this this same kind of it's right there and I never use it. I don't know other people who use this, this sidebar link. So it could conceivably move to manage Jenkins. And, and then for non admin users, if it's needed be placed here as well. Great. Okay, thanks for the guidance. I see a maintainer on the call here. Oh, you do. Oh, very nice. I'm an I'm the interim. I call myself interim maintainer because I adopted to release a guava fix and no one else has stepped up since then. Yeah, well and awful table. An awful icon. Okay, any other topics for today. I think it is jarring because it's, it's the only I think it's the only icon on the left hand side that is an old style icon in the default installation in the, I mean in the default list of suggested plugins. And the support and support and blue ocean are also old style, as we can see in this view but I don't think that they're in the I don't think they're in the suggested plugins list. But the lot of resources is on my instance that's up to date that we use production. Those are the, those are the three ones that look very out of place. All right. Any other topics for today. Thanks everybody. I will stop the share stop the recording.