“Every tester has the heart of a developer … in a jar on their desk.”
— Unknown
Last time, we discussed jumping into the code that would allow us to share a local Scoped Application with the Host instance, but the results are starting to come in from some of the folks who have been testing the set-up process, so we should probably deal with those first. Here’s what we have so far:
- Installation error: Table ‘sys_hub_action_status_metadata’ does not exist
- Not allowing update of property: x_11556_col_store.store_name
- Not allowing update of property: x_11556_col_store.host_instance
- In the setup, the instance name field doesn’t inform you that you only need the instance prefix, not the full url
- You can only collaborate with one host
Many thanks to all of those who have been participating in the testing process. Your efforts are much appreciated. For those of you who tried things out, but neglected to post anything, please feel free to leave a comment on your experience, even if you have no defects to report. All feedback is welcome … thanks!
Now let’s take a look at the issues that have been reported so far. one issue at a time.
Installation error: Table ‘sys_hub_action_status_metadata’ does not exist
It looks like the table ‘sys_hub_action_status_metadata’ is a table related to a version or plugin that I have in my instance, but is not present in the instance on which the test installation was being performed. The version of my instance is glide-rome-06-23-2021__patch0-07-07-2021 according to stats.do. The table in question looks relatively new, with a create date of 2021-07-31 16:24:07, and its name implies some sort of metadata, so I don’t think it is anything critical to the operation of the application. If there are no other issues with this installation, my opinion would be that this error could be safely ignored. To make it go away, I could probably just remove any references to this table from the Update Set. That sounds to me like the best way to go, just to avoid the potential of this error popping up, even though it seems as if it is fairly benign.
Not allowing update of property: x_11556_col_store.store_name
Not allowing update of property: x_11556_col_store.host_instance
These two are basically the same problem for two different System Properties. This is an annoyance that really should be corrected somehow. The work-around that was used was to switch over to the application scope, but that should not be necessary. When you are installing an app for the first time, that scope has not even been established yet, so I need to do something to allow these properties to be modified from the global scope, or from any scope for that matter. I’m not exactly sure how to do that, so I will have to do a little research and see what I can come up with. But this is definitely an issue that needs to be addressed.
In the setup, the instance name field doesn’t inform you that you only need the instance prefix, not the full url
This is very true, and should probably be addressed as well. The snh-form-field tag does provide for a “help” attribute, which appears underneath the label, so that’s probably a good place to throw that onto the screen. I’ll make sure that gets added in there before I release the next version.
You can only collaborate with one host
This is also very true, but that’s the way this particular version was conceived. Back when I was thinking of doing something peer-to-peer without anyone designated as the Host, I was leaning more towards that kind of environment, but once I settled on the Host/Client approach, I was always thinking one Host and many Clients. I can see the benefit of being able to connect to more than one Host, but that’s a little more complicated that I was thinking of taking on at this point, so I think I will file that one in the maybe-I-will-do-that-one-day pile. Good idea, though.
All in all, the list so far is not bad, but I assume that there is more to come. It seems like the biggest issue at this point is the cross-scope updates of the application’s System Properties, but the missing table is also something that might give people pause for no reason. Hopefully, I can find a way to address those before I push out the next version.
Thanks again to everyone who took the time to pull this down and give it a whirl, particularly those of you who posted your findings. And if you did not run into any difficulties and were able to get to the point where every instance has the same list of member organizations, please post those results as well, including the number of instances involved. Any feedback is welcome, and as always, much appreciated. Looking forward to hearing more … thank you all!
Next time out, we’ll see if we can get back to building out the application publishing process and maybe start finding out if we can make that work.
