ASG-RD 2015 - Patch5

[DevOma]

Patch5 of ASG-RD 2015 is available.

If you have already installed any ASG-RD 2015 version you need to close your application and then install the Patch5 version. You don't need to uninstall your old version.

For Upgrade-Users (from version 2012):
If you want to migrate your data from 2012 version you can do inside a new environment in 2015 - so you could not connect to an old environment (as in the past) - you need to create a new environment and select "Environment=>Upgrade from 2012".


not available - please use the previous or next version

The following ReleaseNotes describes the fixed issues and new features.


For any feedback you can use this sub forum or the main forum of ASG-RD.

[dan_linder]

Can you start including the text of the release notes in the thread instead of HTML attachments? As an attachment we have to download the file, then view them in the download directory - lots of unnecessary steps IMHO. Thanks!

[DevOma]

Ok :-)

[rajdude]

"New MultiEdit functionality"

YEE HAA! :-)

[kpg@computercamp.dk]

Creating default values using the multiedit function works, but after opening server properties on any of the selected items default is selected with the correct values but the title states "not defined"

We have a large number of credentials, in 2012 using the end key would navigate to the bottom of the list allowing us to quickly select "none", this no longer works in 2015.

If we open the connect as menu but then decide to click on an already open server tab, the navigation pan hides but the menu remains.
I would be nice if menus closed if they are no longer in focus.

[DevOma]

Please give me some more details...

1. Did you use "MultiEdit Connections"? Which Default values did you set (category name in tree view) - where did you see "not defined"? On a single connection or if use MultiEdit again - existing values are not shown in MultiEdit operations...

2. Where in the UI do you miss this function - in DropDownControls None is always the first item?!?

3. Couldn't reproduce that - if I click on a tab the menu hides - I tried with navigation docked and docked with auto-hide - how do you use the navigation window?

[kpg@computercamp.dk]

1. We used the multiedit connections and tried to set display values.
And the "not defined" was shown on both single and multiedit.
There was no default value on any of the connections prior to the test of multiedit.

2. none is last in out dropdown menus.

3. sry you are correct selecting a tab doesnt leave the menu open.
however clicking into a connected session does (like clicking on the desktop of the active connection)

[DevOma]

1. Did you select "Default values" in MultiEdit - perhaps its not easy to understand the whole functionallity - you can multiedit properties of personal and/or default values at the same time - click first on the category (Display settings) - then choose Default values on the top - then check at least one of the orange checkboxes and set a value behind it - then OK - I tried myself and it's working

2. In Connection-Properties dialog - category "Credentials" - if I drop down the "None" is always the first - do I look at the right place? Or do you mean "Connect as" menu?

3. Yes, youare right - I will check this

[ehl-kpr]

Hello,

Why did you change the connect option now its F4 key Before it was Ctrl-C

Users didnt like this and we have hundreds of users using VisionApp

// Kristoffer

[DevOma]

Hi,

we had several complaints about the shortcuts in "Search" window - because the shortcuts worked no only for the search window but did also in other windows like Navigation - so we first removed the shortcut and then decided to change it until we know why the shortscuts are executed on all docked windows...

[ehl-kpr]

Okay, thx for the reply

// Kristoffer

[thogud]

Hi

Could there be a bug with credential rights with patch 5 (or 4).
We upgraded from Patch 3 to Patch 5 and it seems that noone are able to use credentials they create. Inherit does not work and everything a normal user creates end up with Default Values with Administrators only rights.

Example of a credential a user have created:


Even if it should have inherited:


If I as an administrator goes to security for the same credential I am able to change it back to inherit and every normal user have access.

And if I as an adminstrator is the one who created the credential inherit works as normal. So seems like the change to the credentials with patch 5 broke inherit of rights for non admins?

[DevOma]

I will check that...

[DevOma]

Yes I can confirm this and will fix it asap...

[DevOma]

So I had a deeper look into it - and I don't know if it is really a bug :-) By design it is not possible at the moment to identify the "creator" of an item if it is public - only for private objects is the owner / creator saved...

There is a global permission setting "Security assignments for objects" - please check this first - if I set this permission everything works as expected

But this permission is global and perhaps we need another one on object level??? What do you think - Permissions will be only editable if the user also has rights to edit an object... try it and tell me what you think...

[thogud]

Hi, thanks for the answer

Setting "Security assignments for objects" solved the issue with the missing inherit.
But as you mention I am not sure if this is ideal.

Guess we are a bit of a special use case, as we work as a service provider for several hundred remote customers. Some of them with special security demands.
Currently created a credential folder for each of them. Most of the with inherit from the top folder, but some with special security assignment on the customer folder.

Since this setting is global, and required for inherit of security settings, this actually now forces us to give every credential creator "Security assignments for objects".
And that actually makes them able to change security settings on folder/object level. And they can actually buypass "Default Values" and change folder to Inherit Values. Breaking the special security settings.

So yeah, I do believe it is either required to make inherit work without "Security assignments for objects".
Or make it possible to set this security option on object level.
Ideally we would also want to block the creation of private objects in a similar way as you can block creating public objects, but that is a different issue

[DevOma]

Ok, I will add a new setting in object level...

Creation of private objects should be possible right now - uncheck on folder level "Private objects - Full control"

[thogud]

Ok, I will add a new setting in object level...

Great :D

Creation of private objects should be possible right now - uncheck on folder level "Private objects - Full control"

We tried this, but even if "Private objects - Full control" is unchecked the User can still create private objects. The reason might be that "Edit - Personal data" for public items are automtically activated if the "create sub items" are checked. Seems they are linked together some way.

I guess the idea is for the "Owner - Private" to be greyed out when creating a credential if the "Private objects - Full control" is unchecked. Similar as only Read for public but "Private objects - Full control" checked will give you "Owner - Public" greyed out when creating. But we are unable to get this when testing. Probably due to the "Edit - Personal data" beeing auto checked for public objects?

Update:

---

Ok, I will add a new setting in object level...

After giving this some more thought. I do believe you need to make this setting on subitem level. If not people will be able to buypass the folder security settings and changing them.

But I do believe the ideal situation would be that inherit is done by default without the "Security assignments for objects" (it worked like this on patch 3).
And "Security assignments for objects" is a global or object level setting to give people modify rights to security.

Cause for us atleast we would want inherit to work, but also block people from changing the security settings. That way admins can control the security setting for every subitem that are created by setting this on folder level.

[DevOma]

Ok, fixed the issue with "Private objects are possible even if there is no permission set" - now I will check what happend from Patch3 to Patch5 :-)

[thogud]

Ok, fixed the issue with "Private objects are possible even if there is no permission set" - now I will check what happend from Patch3 to Patch5 :-)

Great :D Btw, is there some other place to send these kind of "possible bugs" or should we just keep using the forum like this? Perhaps there exist some bug tracker / knows issues overview? Cause we also noticed that you need "Delete" rights for public objects to be able to delete your private objects. The "Private objects - Full control" seems to lack the delete rights for your own private objects.