Library variable sets table is not fit to the browser windows

Octopus Server
, ,
1

Hello,

I have recently installed the version 2020.4.6 of Octopus server (from version 2018.8.8), and I see that, when displaying a library variable set, the table is extremely wide and does not fit the width of my browser window. But this is happening only with this condition : when the user does not have enough permission to edit all variables of the list. If the user can edit all variables, the table fits the browser window.

Thank you very much.

3

Hi Johan,

Thank you for reaching out to us to report this interface anomaly.

I’ve tried to replicate this locally but it seems to work okay. Layout issues can be very browser specific so it’s likely that I’m using a different setup to you however. Could you please confirm which browser you are using so I can hopefully reproduce the issue for our engineers?

Best Regards,

Charles

4

Hello Charles, thank you for your reply.

I have the problem in FireFox 80.0.1 (64 bit) and Chrome 86.0.4240.75 (64 bit).

One detail I can give also is that some variables contain long strings with carriage returns characters but they are showing as one long lines in the page, it seems they are not trimmed soon enough.

5

Hi Johan,

I’ve been attempting to replicate this but so far haven’t been able to do so. Would you be able to provide an example value for the variable (anonymised as needed) that I can try? A screenshot showing the issue would also be really useful if at all possible.

Many Thanks,

Charles

6

Hello Charles, sorry for the delayed answer.

I have attached a screenshot. As you can see we have a long string that is trimmed too far away.

The content of the variable is something like this :

D:\somelogpath\logs
D:\somelogpath\logs
D:\somelogpath\logs
D:\webapp\Log
#{ApplicationsInstallPath}\app1\logs
#{ApplicationsInstallPath}\app2\logs
#{ApplicationsInstallPath}\app3\logs
#{ApplicationsInstallPath}\app4\logs
#{ApplicationsInstallPath}\app5\logs
#{ApplicationsInstallPath}\app6\logs
#{ApplicationsInstallPath}\app7\logs
#{ApplicationsInstallPath}\app8\logs
#{ApplicationsInstallPath}\app9\logs
#{ApplicationsInstallPath}\app10\logs
#{ApplicationsInstallPath}\app11\logs
#{ApplicationsInstallPath}\app12\logs
#{ApplicationsInstallPath}\app13\logs
#{ApplicationsInstallPath}\app14\logs\

octopus2020-4-6_wide-libvarset
octopus2020-4-6_wide-libvarset1784×758 16.3 KB

8

Hi Johan,

Thank you for the update and for the screenshot.

I’ve discussed this with the team and I think we may have identified the bug that is causing this:

At first glance this doesn’t explain the permissions issue that you mentioned, however after reflecting on it further I think it covers this. The read/write permissions determine whether the user gets to see the variable editor - which does display correctly (as per the screenshots in the GitHub issue). This means that users who can’t edit will always end up in the broken view and users who can will not.

If you agree with this interpretation you may want to subscribe to the above GitHub issue so you can be notified of updates to it. I’d also be happy to try and investigate further if you think this is a different issue, in which case it’d be great if you could confirm exactly which views/pages are showing this behaviour.

I hope this is helpful. Please let me know if you have any questions.

Best Regards,

Charles

9

Hello Charles,
Thank you for the github issue link, I think this is the same issue that I’m experiencing. I will watch this one closely.

Best regards,
Johan

1 Like
10

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.