Object Repository needs to support dynamic values

Feedback Activities
, , ,
1

We store things like application URLs in config files, we do not hard-code them in our automations.

Here is an example of the problem, using Object Repository. I created a Login Page screen, and it grabs the literal URL. Then I drag that object to my code and, of course, it has the literal URL and can’t be changed without decoupling from the object repository. If I try to edit the Login Page screen and change it to Config(“TCURL”).ToString this is the result:

image

It has the Config reference as a literal string. When I Debug the file, it doesn’t even open Chrome and it generates no error.

Even after manually editing the Browser URL in the Use Application/Browser activity, it still tries to use it as a literal string…

image

2 Likes
3

Also, naming the activity after the object is poor design. The activity should maintain its actual name with the object added to the end. So the result should be “Use Application/Browser - Login Page” not “Login Page” as the name of the activity.

4

And now I’ve discovered that if I decouple the Use Application/Browser activity from the Object Repository, the activities inside it (Type Into, Click, etc) that come from the Object Repository don’t work and don’t even throw an error.

Unless I’m doing something wrong, the Object Repository is useless for us because we don’t hard-code everything.

6

Thanks for the feedback, we’re working on it :+1:

1 Like
7

Any update on this issue, unable to maintain Dyanmic URLs in object repository descriptors.

8

Do we have a release date for this or version number if already fixed? In a real World setting you would always point to test environments (if you have one or access to one) to validate the automation - seems like a crucial function missing to overload url.

Having only just started to get familiar with this I’m saddened to of spent so much time building my object repo for a project now knowing I will have to manually update my urls in the app scope prior to deployments to respecting environments.

Anyone have a workaround?

9

@Cosin any updates on this issue? This is something critical as everyone use Application URLs as variables so that they can execute same scripts in different application environments.
Thank you in advance