Issue Number | 5001 |
---|---|
Summary | [XMetal] Upgrade XMetal to latest version |
Created | 2021-06-24 19:51:30 |
Issue Type | Improvement |
Submitted By | Osei-Poku, William (NIH/NCI) [C] |
Assigned To | Kline, Bob (NIH/NCI) [C] |
Status | Closed |
Resolved | 2023-01-04 18:02:34 |
Resolution | Fixed |
Path | /home/bkline/backups/jira/ocecdr/issue.292881 |
As mentioned in the CDR meeting today, this ticket is to capture discussions on a possible upgrade of XMetal 9.0 to a more current version.
Due to recent issues we have been experiencing in the CDR ( OCECDR-5014, OCECDR-5107 ), and the lack of support due to running XMetal 9.0, we decided to upgrade to the latest stable version of XMetal - 16.0 ([XMetaL Author Enterprise | XML Editor Solution) |https://xmetal.com/content-xmetal-author/]in this sprint.
I will use my Parallels Windows installation to perform the upgrade. That environment is closest to what the majority of our XMetaL users are using.
Please note:
The license included in the email from William for a trial copy of XMetaL 16 is only valid until August 31. We will have to request a new trial license when we get closer to our Pauling release.
Version 17.0 is now the current version.
Should I request evaluation copies of 17 ?
Let's hold off until we're ready to start the work on the ticket in case there's a time limit on how long the evaluation license will work.
I suggest that we do a separate sprint for this XMetal upgrade instead of including it in Pauling as it is now. I think we will be able to more effectively test this upgrade when we are also not testing other tickets in this sprint. Thanks!
That's a possibility, but everyone should be aware that there are some drawbacks to splitting the release.
it would increase the total level of effort required for testing,
as we'd lose the benefit of the overlap for things we'd be testing
anyway for the rest of the Pauling
release;
if we put the XMetaL upgrade into Quinn
(or whatever
we call the release following {}Pauling{
}) we increase the
risk that CBIIT and/or CIT will notice that we're running an unsupported
version and make us do the upgrade on their timetable instead of
ours;
if we instead use Pauling
for the XMetaL upgrade
release, we'd have to defer all of the other tickets to a later release,
and put ourselves back in the game of juggling multiple releases up in
the air, given that we've already started work on some of the
Pauling
tickets.
We have set up a test server for XMetaL 17. I have attached an Excel workbook listing all of the macros which will need to be tested. There are two sheets. The first lists all the macros which can invoked directly, using the menus and toolbar buttons. The second lists all of the event macros which are fired automatically when the application is use, with a description of what to check for to verify that the macro is implemented correctly. There are 163 macros between the two sheets. A couple dozen of those are just buttons on the Special Characters toolbar, so they'll be easy to bang through in a couple of minutes.
Here's the start of a list of things the testers will want to be aware of as they start testing the new XMetaL 17:
the new XMetaL is slower, most notably at startup
as in earlier versions of XMetaL, if you leave it open for a while it sort of "goes to sleep" and on being reawakened an "XMetaL is not responding" message will appear for a bit before it has recovered its state from cache and is ready for business (on the same lines, when XMetaL first starts up, if the user presses a key while the application is the foreground app, or clicks the mouse on XMetaL, you'll see the same message; I'm skeptical that this is the way a well-behaved application would act, but XMetaL has always been that way, I believe)
the Restore last open documents option needs to be turned off (XMetaL crashes otherwise; don't remember for sure, but this may have been true for earlier versions of XMetaL)
you'll want to keep Task Manager open on the Details view (so if you need to kill a rogue XMetaL process you don't clobber someone else's on the shared machine)
DEV
is the only tier supported right now
except for the loader, the new dialog boxes look (and behave) pretty much like the old ones, but you shouldn't expect pixel-for-pixel replication
one or two macros which were complete broken (for example, Show Linked Object) are working now
you will probably want to register a default app for viewing image files before testing the macros for fetching media (I have installed IrfanView on the machine globally, and that's a good candidate; see the instructions for registering that app as the default viewer)
I have installed Libre Office on the XMetaL 17 test machine, as it didn't have MS Office.
Well, the reason I was surprised that I hadn't attached the Excel workbook listing the macros to be tested is that I actually HAD attached it (back on January 4). So please take a look.
Commits:
~vshields Here are the instructions for the CDR/XMetaL 17 setup.
I am attaching the list of CDR user who will need access to the VM for testing XMetal 17. The power users (yellow highlight) have access now. I will let you know when to add all other users. Thanks!
Verified on QA.
Verified on PROD. Thanks!
File Name | Posted | User |
---|---|---|
Active_CDR_XMetaL_Users-20221109131349.xlsx | 2023-03-15 11:06:08 | Osei-Poku, William (NIH/NCI) [C] |
macros-20221228.xlsx | 2023-01-04 18:00:07 | Kline, Bob (NIH/NCI) [C] |
Elapsed: 0:00:00.001426