We have a new visual profile that should be followed in the web administration.
Created attachment 1097 [details] HTML file for testing styling of all different types of input elements The attached HTML uses our styles from input.css, constants.css and fonts.css (uses those installed on localhost:300) and displays a complete list of all types of <input>, <button>, <select> and <textarea>. It's good for testing and to see if things match well together.
There is some issue on the Galaxy Tab where our content gets scaled oddly in portrait mode. It happens on all three browsers (Edge, Firefox, Chrome), so it doesn't look like a browser bug. It seems to have something to do with "min-width: min-content;", as the effect goes away if I remove that. We'll need to investigate this more and see if we can prevent the scaling and instead get the scrolling that we are really after.
Red herring. Removing that just happened to make the content more narrow. Using something simple like "width: 1200px;" also triggers the issue. I think it might just be general viewport shenanigans. We probably need to disable some magic using the viewport meta tag.
Edge on Android is also doing something magical with font sizes. It enlarges some of the font on the health page. Can't see any such effect in the other browsers.
(In reply to Pierre Ossman from comment #187) > Red herring. Removing that just happened to make the content more narrow. > Using something simple like "width: 1200px;" also triggers the issue. > > I think it might just be general viewport shenanigans. We probably need to > disable some magic using the viewport meta tag. Indeed it was. And setting the viewport meta tag solves it. Unfortunately, all browsers seem to ignore that tag when in "desktop site" mode. And to make things worse, Edge is in that mode by default on tablets.
(In reply to Pierre Ossman from comment #196) > > Unfortunately, all browsers seem to ignore that tag when in "desktop site" > mode. And to make things worse, Edge is in that mode by default on tablets. I can't find any sane way to prevent this, or to make sure our page fills even this larger size. :/ As a workaround, I can make sure we get our dark blue below the page, instead of white. This makes things look less odd as it matches the colours of the bottom bar.
Reported the odd layout viewport behaviour on Android to the browsers: https://bugzilla.mozilla.org/show_bug.cgi?id=1815657 https://bugs.chromium.org/p/chromium/issues/detail?id=1413997
(In reply to Repository Bot from comment #172) > ------------------------------------------------------------------------ > r39632 | ossman | trunk/ctc/tladm/tlwebadm/www/styles/ > > Handle table rounding entirely in <table> > Unfortunately, this doesn't work in WebKit-based browsers, such as Safari. :/ Filed a report here: https://bugs.webkit.org/show_bug.cgi?id=251909 I guess we'll need to revert to some duplication to handle WebKit...
(In reply to Pierre Ossman from comment #206) > > As a workaround, I can make sure we get our dark blue below the page, > instead of white. This makes things look less odd as it matches the colours > of the bottom bar. This has weird side effects on (at least) Chrome. It shows that dark blue whilst the page is loading in some cases, which can be very jarring. It doesn't seem to happen under normal usage, but developers see it more often. I guess disabling the cache makes the issue more likely. It can easily be provoked by using the throttling function in the developer tools. I guess that means normal users with poor bandwidth might also see this more often.
I tried resolving this by using a gradient. My idea was that the <html> background would be white for the visible area, and then switch to dark blue outside of that. Unfortunately, this doesn't work. At least Chrome repeats the background rather than continuing it. I.e., the immediate area outside the page gets the same background as the start of the page. And the start needs to be white to avoid the switching.
My next attempt is having something change as the page loads. The goal being that things are white until the page has finished loading, and then switches to dark blue. The dark blue is needed to match with the bottom bar, so there is no value in having it until then. Variants of this can simply be to hide the <html> element or change its background colour. Unfortunately, something magical seems to be going on here. The initial dark blue that Chrome shows doesn't seem to come from the CSS directly. Instead, it seems to be something that Chrome caches from a previous render of the page. Perhaps to give a nicer page load for slow pages? I tried this by removing the background from :root. I then added it with the selector :root.loaded instead. I added an inline script after the CSS which simply adds this "loaded" class. This works because inline scripts will block until all preceding CSS has finished loading. Given this, the timeline seems to be: 1. Browser loads (but doesn't parse) the entire HTML 2. Browser starts parsing, finds CSS entries and starts loading those 3. Browser encounters <script>, stops parsing and waits for the CSS 4. Somewhere during the loading of some of the CSS, the background switches to dark blue 5. The CSS finishes loading, unblocking parsing of the HTML, which loads the rest of the page, and we get a white <body> Further evidence that this is some caching is that this only works if the *previous* page was dark blue. If I remove the background, then do a reload to get things updated, then I can no longer reproduce the issue (reasonable). If I then add the background again, then the first reload still doesn't show the problem. But the next attempt will.
Issue reported to Chrome here: https://bugs.chromium.org/p/chromium/issues/detail?id=1420876
There are two areas that were problematic concerning vertical alignment in our tables: * Textareas in Chrome. * Text input fields with different fonts next to each other in the same row. In general, we want items in our tables to align rows according to the baseline of the first line of text in each cell. The “vertical-align: baseline” property does exactly that, except for on textareas in Chrome-based browsers. In Chrome, a baseline-aligned textarea seems to both expand upwards and not align any text-line to surrounding text. These behaviors are unwanted. I reported a bug for that: https://bugs.chromium.org/p/chromium/issues/detail?id=1427109 It isn't obvious how textareas should be aligned since they contain multiple lines of text. However, Chrome doesn't seem to aim for any of the text rows inside the textarea when vertically aligning them. Regarding mixed fonts, the browsers behave correctly by properly aligning the baselines of the texts. However, different fonts can have different baselines, this is the case with Space Mono and Poppins. Inputs with these two fonts occasionally appear on the same row in Web Admin. Both these issues have now been worked around using “vertical-align: top”. This change in alignment was applied to all elements containing padding above their text. By doing so, we align the top edges of elements and enable textareas to expand downwards.
Created attachment 1111 [details] HTML file for testing styling of all different types of input elements Updated inputs.html with toggle switches, among other things.
Radio buttons now have proper highlighting when hovering with the cursor over checked radio button. > Remarks: A few different approaches to fixing the missing/faulty highlighting on radio buttons were explored before resorting to the workaround in comment 406. Highlighting on elements is normally achieved by mixing a base background color with a semi transparent background image, using the background blend mode called overlay. Radio buttons (as we have styled them) use a border instead of a background to show the checked state and hence, the normal highlight method does not work, since borders are always on top of the background. Explored approaches, all using the normal highlight method without using the styled border: * Drawing the white center of the radio button with an SVG as a background image. * Drawing the white center and the blue ring around it, both as SVG background images. - With SVGs being the same size as the radio button. - With radio button being larger than the SVGs (25px resp. 15px). All four approaches failed to achieve a consistent look. The background SVGs would, to varying degrees, be placed off center and become cropped to look non circular when touching the border of the element. This would sometimes only be visible at a certain zoom level. We also discussed if this could have been the result of having the following properties set on the radio button instead of aligning child elements to the top left corner: * display: inline-flex; * justify-content: center; * align-items: center;
Created attachment 1112 [details] HTML file for testing styling of all different types of input elements Updated inputs.html with multi-selects.
(In reply to Samuel Mannehed from comment #386) > There are two areas that were problematic concerning vertical alignment in > our tables... Chrome/Edge has recently implemented a new CSS property called “baseline-source” which allows the developer to choose between aligning towards first or last baseline of text (or auto behavior). Using “baseline-source: first” with “vertical-align: baseline” on textareas resolves the alignment issues on Chrome. Unfortunately, baseline-source isn't implemented in webkit yet, so Safari users would still have problems. See the webkit bugzilla entry here: https://bugs.webkit.org/show_bug.cgi?id=249094 See the draft specification for baseline-source here: https://drafts.csswg.org/css-inline-3/#baseline-source We'll see if we can use baseline-source when possible and the current workaround as some sort of fallback when necessary.
Created attachment 1119 [details] Table headers centered on iOS 15.7.3 I do not see this on the new iPad with iPadOS 16.3.1. I see the same on my iPhone that also has iOS 15.7.3.
There is a vertical alignment issue with radio buttons, checkboxes, and toggle switches. We have made adjustments w.r.t “vertical-align: middle” to make these elements align to the middle of capital letters. When an item is “middle”-aligned, we assumed it would align according to the middle of small letters. Thus, we nudged the elements a bit upwards to be aligned the way we want. Despite our calculated numbers being correct, we didn't end up with a correct vertical alignment. Our numbers were calculated based on the font “Poppins”, and our incorrect assumption was that only the font of the text that we wanted to align with mattered. Looking closer at MDN's description of “vertical-align: middle” (https://developer.mozilla.org/en-US/docs/Web/CSS/vertical-align): > Aligns the middle of the element with the baseline plus half the x-height of the parent. We can see that it uses the x-height of the parent. The default font in web admin is “Mulish”, not “Poppins”, so the font of the parent elements of the radio buttons, checkboxes, and toggle switches is “Mulish”. Changing the font of the parent element fixed the alignment, but this isn't a robust solution.
Before landing on “vertical-align: middle” we attempted to use “vertical-align: baseline” but found that it behaved strangely in some cases. After further inspection, we have found that this is due to the ::after pseudo-element the radio buttons and checkboxes have. The baseline of the text inside the pseudo-element was used. By setting “position: absolute” on both ::after and ::before, we can disregard the pseudo-elements from the layout and not have them impact the baseline. Doing so aligns the bottom of the radio/checkbox with the baseline of the text, no matter the font of the parent. From this bottom baseline, we can apply a similar vertical adjustment to get the element aligned with the middle of capital letters like we want.
Lastly, on a non scaled monitor, capital letters in “Poppins” renders as 10px when using 15px font-size. The height of our radio buttons and checkboxes is currently 15px, and the height of our toggle switches is 17px. These heights are odd numbers, while the rendered height of capital letters is an even number, this means the vertical centering will end up nudged 1px in one direction. To achieve perfect centering, we should consider modifying the height of these elements to an even number.
(In reply to Frida from bug 8083, comment #55) > I think I found a regression from this bug. When master service is turned > off you get an error page when surfing to the session page. And this is the > traceback in tlwebadm.log: > > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] ---------------------------------------- > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] Exception happened during processing of request from ('::1', 52962, 0, 0) > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] Traceback (most recent call last): > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] File "/opt/thinlinc/modules/thinlinc/forkingserver.py", line 62, in process_request > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] self . finish_request ( request , client_address ) > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] File "/opt/thinlinc/modules/thinlinc/httpserver.py", line 407, in finish_request > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] super ( ) . finish_request ( request , client_address ) > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] File "/opt/thinlinc/modules/thinlinc/tlstunnel.py", line 71, in finish_request > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] self . TLSRequestHandlerClass ( request , client_address , self ) > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] File "/opt/thinlinc/modules/thinlinc/httpserver.py", line 78, in __init__ > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] super ( ) . __init__ ( request , client_address , server ) > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] File "/usr/lib64/python3.10/socketserver.py", line 747, in __init__ > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] self.handle() > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] File "/opt/thinlinc/modules/thinlinc/httpserver.py", line 380, in handle > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] super ( ) . handle ( ) > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] File "/usr/lib64/python3.10/http/server.py", line 433, in handle > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] self.handle_one_request() > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] File "/opt/thinlinc/modules/thinlinc/httpserver.py", line 155, in handle_one_request > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] super ( ) . handle_one_request ( ) > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] File "/usr/lib64/python3.10/http/server.py", line 421, in handle_one_request > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] method() > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] File "/opt/thinlinc/modules/thinlinc/tlwebadm/server.py", line 168, in do_GET > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] self . post_or_get ( "do_GET" , ooOOOoOO0 ) > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] File "/opt/thin > > linc/modules/thinlinc/tlwebadm/server.py", line 182, in post_or_get > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] oO00o00OO , iIi1 = getattr ( OoOo00 , action ) ( i1iI1i , query , oO00o00OO ) > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] File "/opt/thinlinc/modules/thinlinc/tlwebadm/main.py", line 133, in do_GET > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] IiII = self . _content_to_bytes ( > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] File "/opt/thinlinc/modules/thinlinc/tlwebadm/main.py", line 112, in _content_to_bytes > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] return self . _render_page ( page_name , content ) . encode ( 'utf-8' ) > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] File "/opt/thinlinc/modules/thinlinc/tlwebadm/main.py", line 105, in _render_page > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] return str ( self . _main_page ) > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] File "/opt/thinlinc/modules/thinlinc/Cheetah/Template.py", line 1053, in __unicode__ > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] return getattr(self, mainMethName)() > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] File "_opt_thinlinc_share_tlwebadm_templates_main_tmpl.py", line 121, in respond > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] File "/opt/thinlinc/modules/thinlinc/Cheetah/Filters.py", line 131, in filter > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] output = super(MaxLen, self).filter(val, **kw) > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] File "/opt/thinlinc/modules/thinlinc/Cheetah/Filters.py", line 40, in filter > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] return unicode(val) > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] File "/opt/thinlinc/modules/thinlinc/Cheetah/Template.py", line 1053, in __unicode__ > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] return getattr(self, mainMethName)() > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] File "_opt_thinlinc_share_tlwebadm_templates_status_sessions_tmpl.py", line 217, in respond > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] File "/opt/thinlinc/modules/thinlinc/Cheetah/NameMapper.py", line 293, in valueFromSearchList > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] _raiseNotFoundException(key, searchList) > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] File "/opt/thinlinc/modules/thinlinc/Cheetah/NameMapper.py", line 178, in _raiseNotFoundException > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] raise NotFound(excString) > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] thinlinc.Cheetah.NameMapper.NotFound: cannot find 'sess_details' > > 2023-04-24 14:27:07 ERROR tlwebadm[45859]: [::1] ---------------------------------------- Turned out, this comment should have belonged to this bug. The issue has now been solved.
(In reply to Samuel Mannehed from comment #467) > Lastly, on a non scaled monitor, capital letters in “Poppins” renders as > 10px when using 15px font-size. The height of our radio buttons and > checkboxes is currently 15px, and the height of our toggle switches is 17px. > These heights are odd numbers, while the rendered height of capital letters > is an even number, this means the vertical centering will end up nudged 1px > in one direction. To achieve perfect centering, we should consider modifying > the height of these elements to an even number. We have now adjusted the size of the elements to be even numbers. (In reply to Samuel Mannehed from comment #466) > From this bottom baseline, we can apply a similar vertical adjustment to get > the element aligned with the middle of capital letters like we want. Despite our efforts, the resulting renderings are still not perfectly centered in all cases. In Chrome, Firefox, and Edge we sometimes get rounding errors in the rendering because the element's coordinates aren't integers internally. When rendering, browsers are bound to draw on integer screen coordinates (on regular DPI). The method we use to nudge the element's vertical-align down from the baseline, results in an offset of ~2.75px with our default font-size (15px). This offset is the difference in position between the radio/checkbox/toggle element and its label. Depending on the general positioning of these two elements, we might end up with coordinates rounded differently for the element and the label, respectively. When rendered, if one is rounded up and the other rounded down, we see the issue. We want the offset to be dependent on the font-size, and unfortunately, Chromium-based browsers don't have any “round()” function available in CSS yet: https://developer.mozilla.org/en-US/docs/Web/CSS/round Note that rendering must work differently in WebKit somehow, since we don't see the same issue in Epiphany and Safari.
We have decided to postpone solving the rounding issue mentioned in comment 525 right now. Since the important thing here is the rendered distance between the element and its label, the proper solution would be to use a rounded integer as the vertical-align offset. As mentioned in comment 525, the CSS function "round()" is not fully available, and the last main browser without support is Chrome. Once this bug is resolved, we should revisit this: https://bugs.chromium.org/p/chromium/issues/detail?id=1407473&q=css%20round%28%29&can=2
(In reply to Samuel Mannehed from comment #526) > We have decided to postpone solving the rounding issue mentioned in comment > 525 right now. Since the important thing here is the rendered distance > between the element and its label, the proper solution would be to use a > rounded integer as the vertical-align offset. As mentioned in comment 525, > the CSS function "round()" is not fully available, and the last main browser > without support is Chrome. Once this bug is resolved, we should revisit this: > > https://bugs.chromium.org/p/chromium/issues/ > detail?id=1407473&q=css%20round%28%29&can=2 This has been moved to bug 8148.
Branched out a separate bug (bug 8149) dealing with updating TAG screenshots to reflect tlwebadm's new visual profile.
Tested server build 3261 on SLES 15 with the following browsers: - Firefox v. 113 (on Fedora 37) - Edge v. 113 (on Windows 10) - Safari v. 16.4 (on macOS 13) Did not find anything that looked out of order. Below is a summary of what was tested. Where applicable, I checked that the changes also got saved in the hconf, these cases are indicated by a (^). On Safari, note that tables get one vertical, thin line in our table heading. This is due to using fixed table layout (since bug 8121) and showing this line is expected behaviour. * All pages - Buttons and links leads where supposed to and have correct hover/click styling - Look good in different page sizes - Padding/margins/font size look reasonable * Menu - Hover/click look good * Welcome - Picture is sharp * System health - Service status shows correct status - User/group lookup works, and gives error if group/user can't be found * Status - Licence graphs look ok and can generate custom graph - Numbers for load and sessions look reasonable and match with tlctl - Shadow button works as expected, and opened client has the correct values prefilled * VSM - Subcluster - add new, edit and delete (^) - Stop and start services on the master and agent page - Master - change sessions per user (^) - Master - add to/remove from option selects Allowed groups and Allowed shadowers (^) - Agent - change hostname and xserver args (^) * Profiles - Add/edit/delete greeting text and introduction text (^) - Profile List - change default profile (^) - Profile List - add/edit/delete profile (^) - Profile List - reorder profiles top/up/down/bottom (^) - Profile List - make profile active/inactive (^) * Locations - Locations - add/edit/delete location and add/edit/delete printer (^) - Terminals - add/edit/delete terminal and add/edit/delete printer (^) * TLDC - App.groups - add/edit/delete group (^) - App.groups - add to/remove from option selects "Applications added to menu", "Applications added to desktop" and "Thinlinc profiles with this app. group" (^) - App.groups - add/remove linux group and users (^) - App.groups - get errors if linux group or user doesn't exist - Apps (Man) - add/edit/delete app (^) - Apps (Man) - links to correct "Used in app.group" - Apps (Sys) - links to correct "Used in app.group" - Menu str. - add/edit/delete menu (^) - Menu str. - can't delete menu that is in use
Textareas with fancy placeholders unfortunately have problems with resizing. By default, you are allowed to resize a textarea, but the surrounding <span> (.input) we use for fancy placeholders doesn't properly follow the resized textarea inside. This, in turn, leads to two problems: * When decreasing the textarea width, the placeholder text width doesn't decrease or get hidden (leaving it too big). * When increasing the textarea width, the textarea expands but not the popup (see Profile List). Other popup textareas expand the popup when resized. There might be other potential issues as well, but the two above are the only ones observed so far. In practice, we only have textareas with fancy placeholders on two pages; Introduction Texts and Profile List. Out of these two, only the textareas on the Profile List page are resizable horizontally. Vertical resizing works fine.
The behavior described in comment 550 is no longer a problem, since horizontal resize has now been disabled on textareas with fancy placeholders. The fact that these textareas can't be resized has been broken out to bug 8153.
(In reply to Linn from comment #549) > On Safari, note that tables get one vertical, thin line in our table > heading. This is due to using fixed table layout (since bug 8121) and > showing this line is expected behaviour. To clarify, this isn't expected behavior, but it is a known issue. This was reported to Safari here: https://bugs.webkit.org/show_bug.cgi?id=256883 Tested the same things as in comment 549 in Chrome 112 (Fedora 37) using server build 3263 installed on Fedora 37. With that, this bug can be closed.
Firefox 115 has broken things, unfortunately. Most tables in Web Admin are very broken and get a height of several million pixels. This makes these pages completely unusable. Due to the severity we need to add a workaround until they fix things. I reported the issue to Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1843086
A workaround has been committed now. I have verified that our Web Admin tables now look correct in Chrome, Firefox and Epiphany on Fedora, as well as in Chrome and Firefox on Android.
Tested with server build #3320 on RHEL8 and ThinLinc Web Access in Fedora 38 Firefox 115 Chrome 114 Epiphany 44.3 Win 10 Firefox 115 Chrome 114 Edge 114 macOS 13.4 Firefox 115 Chrome 114 Safari 16.5 Edge 114 Android 13 Firefox 115 Chrome 114 Edge 114 The tables are displayed as intended in all platforms/browsers mentioned above. Closing.
We have found a regression in how the backend code for VSM Master in tlwebadm handles groups as allowed shadowers. If a group has been added to allowed_shadowers in shadowing.hconf, tlwebadm will interpret is as a nonexistent user and return '#unknown' instead of the group name. This results in the group name being replaced with '#unknown' in the config file when it is saved through tlwebadm. '#' also happens to be the comment character in hconf-files, which means that everything after a group entry would be commented out.
This regression was introduced in comment 191 where the presentation of allowed shadowers in tlwebadm was updated.
This has been fixed now, The unit test were previously not taking into account that allowed_shadowers can contain group names. They have now been updated so that the mock hive contains both a user and a group. This caught the error we saw in tlwebadm, and the tests all pass after the introduced fix. Additionally, I added users and groups to the config files (both existing and nonexisting), and verified that these remained unchanged in the hive files when adding and removing other users in tlwebadm.
Tested with server build 3357 on Fedora 37. On page VSM -> Master, when adding a group directly in the hconf-file, that group is now preserved when adding users through the interface. However, note that the groups are presented as '+<group name> (n/a)', where n/a is the id. This is because we are assuming this list only will contain user names and no group names, and hence we cant get the correct group id. The code for handling groups and users when adding a new Application group in TLDC was also touched, and that functionality still works properly, both when adding users and groups through webadmin and directly in the hconf file. Also looked through the code changes, looks good!
