Code displaying in UI after Zope5 upgrade

[aked...@gmail.com]

Hello,
Sorry for starting a new thread so soon. I am working on installing Zope5 with Schedulix and believe I have it most of the way in place. I am running into an issue where when I click "Take Off" in the UI after the upgrade it displays the code instead of rendering it. I have tried in Chrome and Edge and was curious if you might have seen this before.




Thank you!
Andrew

[Ronald Jeninga]

Hi Andrew,

no problem, that's what the group is for.

I can't remember having seen this issue in the past. But hey, life would be boring if I'd seen everyything already ;-)

Since I know Zope5 works fine if you set it up correctly, you must have made a mistake somewhere on the way.

Note: I'm not bllaming you, I make mistakes all the time myself. That's human.

Maybe you can elaborate a little what you've done to upgrade?

Basically you'll have to setup Zope5 just like Zope2 but you'll have to use the files from the zope4 directory, mainly because of the incompatibilities between Python2 and Python3.

If you only have a few users defined, it'll be best to create them manually again in the new GUI.

That's a bit of a hassle, I know, but at the same time it is guaranteed to work.

If you've installed the system using the rpms it looks like I was the one that made the mistakes.

In that case I'll fix it and create new rpms. Please advise.

Best regards,

Ronald 

[aked...@gmail.com]

This very likely is me haha I appreciate the help!! It was mostly installed following the Zope4+ install steps in https://schedulix.org/Downloads/installation_os_en-2.10.pdf with some slight changes as needed to get things to install in our environment. 

Note: We are on Schedulix version 2.9, installing zope 5.8.6 with Python 3.8 on Linux and I set things up to be in parallel with our other zope install as closely as possible

Install steps followed:

Run these commands as root:
yum install python3
yum install python3-devel

Run these commands as schedulix user:
Environment set up:
export INSTALLDIR=/usr/bin/schedulix/software
export ZOPE5VENV=Zope5
export ZOPE5DIR=$INSTALLDIR/$ZOPE5VENV
cd $INSTALLDIR

curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py ( work around needed because environment wasn't setting up pip in venv correctly) 
python3 -m venv --without-pip $ZOPE5VENV
source /usr/share/schedulix-2.9/software/Zope5/bin/activate
python3 get-pip.py
cd $ZOPE5DIR
bin/pip3 install -U pip wheel
bin/pip3 install zope
bin/pip3 install Products.ExternalMethod
bin/pip3 install Products.Sessions
bin/pip3 install Products.SiteErrorLog
bin/pip3 install Products.PythonScripts
bin/pip3 install Paste

$INSTALLDIR Directory looks like this:
Jun 12  2019 Zope
Oct 27 15:19 Zope5
Oct 27 15:19 .
Oct 27 16:50 ..

Create a Zope instance for schedulix!Web:
cd $INSTALLDIR
export ZOPE5INSTANCE=/usr/bin/schedulix/schedulixweb4
$ZOPE5DIR/bin/mkwsgiinstance -d $ZOPE5INSTANCE \ -u sdmsadm:<password>

Start and stop the server:
$ZOPE5DIR/bin/runwsgi -v $ZOPE5INSTANCE/etc/zope.ini

Pressing Strg-C or clsing the terminal window will stop the instance again.

Add zope5 directory:
cd $BICSUITEHOME 
download the zope4 folder from https://github.com/schedulix/schedulix/tree/v2.9/zope4 (rename to zope5)
upload zope5 folder to /tmp
cp -R /tmp/zope5 .

$BICSUITEHOME Directory looks like this for zope:
May 30  2019 zope
Jun 12  2019 schedulixweb
Oct 27 16:50 zope5
Oct 27 18:17 schedulixweb4

Set up zope5 extensions:
cd $ZOPE5INSTANCE
mkdir Extensions
cd
ln -s $BICSUITEHOME/zope5/Extensions/*.py .
cd ..
ln -s $BICSUITEHOME/zope5/BICsuiteSubmitMemory $ZOPE5DIR/lib/python3*/dist-packages/Products
ln -s $BICSUITEHOME/zope5/StringFixer $ZOPE5DIR/lib/python3*/dist-packages/Products
mkdir import
cd import
ln -s $BICSUITEHOME/zope5/import/SDMS.zexp .
cd $ZOPEINSTANCE/etc

mv zope.ini zope.ini.$$;
sed 's/^\(host[         ]*=[    ]*127.0.0.1\)/# \1/
s/^\(^port[        ]*=[    ]*8080\)/# \1/i
/port[     ]*=[    ]*8080/a listen = *:8080' < zope.ini.$$ > zope.ini;

$ZOPE5INSTANCE Directory looks like this:
Oct 27 16:54 Extensions
Oct 27 16:55 import
Oct 27 16:59 etc
Oct 27 18:08 var
Oct 27 18:17 .
Oct 27 18:19 bin

Links looks like this:
Extensions:
sdms.py -> /usr/bin/schedulix/zope5/Extensions/sdms.py
myeval.py -> /usr/bin/schedulix/zope5/Extensions/myeval.py
bicsuite_tx.py -> /usr/bin/schedulix/zope5/Extensions/bicsuite_tx.py

Import:
SDMS.zexp -> /usr/bin/schedulix/zope5/import/SDMS.zexp

for ../Zope5/lib/python3.8/dist-packages/Products:
BICsuiteSubmitMemory -> /usr/bin/schedulix/zope5/BICsuiteSubmitMemory
StringFixer -> /usr/bin/schedulix/zope5/StringFixer

Start the server again
$ZOPE5DIR/bin/runwsgi -v $ZOPE5INSTANCE/etc/zope.ini

Follow the steps on page 33 of the installation guide to set up Zope: http://www.schedulix.org/de/Downloads/installation_os_en-2.9.pdf

Please let me know if you would like any additional information!

Thank you!

[Ronald Jeninga]

Hi Andrew,

since it is weekend, I'm not going to repeat your steps on my computer.

But what I did is to compare your steps with my rpm scripts (you find them in the schedulix/lib directory).

So far the only thing which is really different is that you don't create the RemoteUserFolder link.

(You also don't install the python-ldap package, but that is only required when you want to set up SSO, as far as I know).

The script installs Zope 5.1.1, I think, but that shouldn't make that much of a difference.

I'm going to try to install Zope 5.8.6 myself though. But that's a nice task for Monday.

Hence if the RemoteUserFolder link doesn't resolve your issue, you'll have to wait a few days.

No worries, we'll get it fixed :-)

Best regards,

Ronald

[aked...@gmail.com]

Thanks Ronald! Definitely enjoy your weekend!!

For Monday:
I pulled down the RemoteUserFolder from Master since it wasn't in the v2.9 branch and uploaded it to the same location as the other folders and created the link:
ln -s $BICSUITEHOME/zope5/RemoteUserFolder $ZOPE5DIR/lib/python3*/dist-packages/Products

It barked about the ldap package so I installed it with these two commands:
yum -y install openldap-devel

bin/pip3 install python-ldap

It failed to run with this error and I found that AccessControl had deprecated a module that was being imported:
Error:
 File "/usr/share/schedulix-2.9/software/Zope5/lib64/python3.8/dist-packages/Products/RemoteUserFolder/RemoteUserFolder.py", line 58, in <module>
    from AccessControl.Role import RoleManager, DEFAULTMAXLISTUSERS
ImportError: cannot import name 'RoleManager' from 'AccessControl.Role' (unknown location)

Note in file AccessControl.Role script:
    "The functionality of AccessControl.Role has moved to"
    " AccessControl.rolemanager. Please import from there."
    " This backward compatibility shim will be removed in AccessControl"
    " version 6.",

deprecated(
    "The functionality of AccessControl.Role has moved to"
    " AccessControl.rolemanager. Please import from there."
    " This backward compatibility shim will be removed in AccessControl"
    " version 6.",
    DEFAULTMAXLISTUSERS='AccessControl.rolemanager:DEFAULTMAXLISTUSERS',
    _isBeingUsedAsAMethod='AccessControl.rolemanager:_isBeingUsedAsAMethod',
    _isNotBeingUsedAsAMethod='AccessControl.rolemanager:_isNotBeingUsedAsAMethod',  # noqa
    class_attrs='AccessControl.rolemanager:class_attrs',
    class_dict='AccessControl.rolemanager:class_dict',
    classattr='AccessControl.rolemanager:classattr',
    gather_permissions='AccessControl.rolemanager:gather_permissions',
    instance_attrs='AccessControl.rolemanager:instance_attrs',
    instance_dict='AccessControl.rolemanager:instance_dict',
    reqattr='AccessControl.rolemanager:reqattr',
)

Fix:
I edited the RemoteUserFolder.py script-
from AccessControl.Role import RoleManager, DEFAULTMAXLISTUSERS to
from AccessControl.rolemanager import RoleManager, DEFAULTMAXLISTUSERS

After trying to start the server I got this error:
  File "/usr/share/schedulix-2.9/software/Zope5/lib64/python3.8/dist-packages/Products/RemoteUserFolder/__init__.py", line 14, in initialize
    context.registerHelp()
AttributeError: 'ProductContext' object has no attribute 'registerHelp'

This one I wasn't too sure one so I'll hold off going any further.

Thanks again for all the help! :)
Andrew

[Ronald Jeninga]

Hi Andrew,

Dieter did some fixing in the Python code (mainly your suggestions). I'll check that in as soon as I was able to setup a recent (5.8.6) Zope together with a recent (3.8) Python.

It is very well possible we'll find some more incompatibilities which I'll repair on the way then.

As it seems it was neither you nor us that made some mistake other than using a recent Zope.

As soon as I can report results, I'll post them.

Thank you very much for reporting your issue! It'll improve our system.

Best regards,

Ronald

[aked...@gmail.com]

Perfect, thank you! I'll keep an eye out for any next steps. Very much appreciated :)

Thanks again!
Andrew

[Ronald Jeninga]

Hi Andrew,

I just wanted to let you know I didn't forget about this issue.

You might have noticed that I've been pretty busy in the group in the last few days.

Anyway, I am making progress.

I've tweaked the RHEL8 rpms a little and was able to install a Zope 5.8.6 running with Python 3.9 on a RHEL9 compatible system.
And the nice thing is that I get the page source code displayed too.

This means that you didn't make a mistake in your initial attempt to install Zope5. It is something else that spoils the fun.

And furthermore I now have a testcase which I can investigate without having to send messages back and forth (that will definitely speed up the process).

I'm pretty confident I'll crack this nut at latest early next week.

Best regards,

Ronald

[aked...@gmail.com]

Thanks Ronald,
I completely understand! I definitely see how busy things are for you and really appreciate your effort. Glad to see the issue was repeatable too :)

Have a great weekend!

Thank you!
Andrew

[Ronald Jeninga]

Hi Andrew,

I was able to find a (the?) cause of the problem.

The content-type of the returned pages is set to text/plain, not text/html.

After modifying the sources within Zope, I got it running.

Since that was just a bit of hacking, I'll have to discuss the best solution here with Dieter.

But I'm relatively confident I'll be able to present a fixed SDMS.zexp next Monday or Tuesday.

My weekend will be even better now ;-)

And of course a great weekend to you too!

Best regards,

Ronald

[Ronald Jeninga]

Hi Andrew,

first of all, the two changes you've made to RemoteUserFolder.py and __init__.py are correct and I'm going to make similar changes and check them in into git.

So I assume you have a running Zope instance that still shows the issue you've started with.

Since I'll have to take care of several schedulix releases (2.9, 2.10, 2.11) and several platforms for the rpms (RHEL 7, 8 and 9), it is quite a bit of work to get everything right.

But in the end the required change to fix your issue isn't that big; you only need to add 3 lines of code.

Instead of letting you wait, I'll tell you how to fix the problem.

First you open the management page of Zope. (You need to sign in as sdmsadm).

Something like http://localhost:8080/manage

In the root folder you'll see a folder called SDMS. Just click on the name to get there and proceed with Common -> Pages.

Now you open the script HeadSetup. The first 3 lines should be

REQUEST = context.REQUEST
html = ''
html = html + '<META charset="utf-8">\n'

Now you change them to 

REQUEST = context.REQUEST

REQUEST.RESPONSE.setHeader('Content-type', 'text/html')
html = ''
html = html + '<META charset="utf-8">\n'

You then save the script (there should be a "Save Changes" button at the bottom of the page).

The next script to modify is called EditorFrame (it resides in the same folder).

The first few lines look like:

context.Common.Util.initREQUEST()

REQUEST=context.REQUEST
form = context.EditorForm()

html = ''
html = html + '<HTML>\n'

And you modify them to 

context.Common.Util.initREQUEST()

REQUEST=context.REQUEST
form = context.EditorForm()

html = ''
html = html + '<HTML>\n'
html = html + '<HEAD>\n'
html = html + context.Common.Pages.HeadSetup()

After saving the script you should be fine.

These two changes force Zope to set the Content-type to text/html instead of text/plain.

I think that the Zope developers have changed the default Content-type for some (to me non apparent) reason.

Anyway, I think it is good programming style not to rely on defaults too much, so I'm happy with this change. 

If you encounter (other) problems, please tell me.

Best regards,

Ronald

[aked...@gmail.com]

This is great Ronald, thank you! I will give this a try within the next few days and will report back how things go.

Thank you again!
Andrew

[aked...@gmail.com]

Hello Ronald,
Looks like things are rendering appropriately now!

I will continue to do some testing and let you know if anything else shakes out but thank you so much for all the help!

[Ronald Jeninga]

Hello Andrew,

thank you for the feedback!

I love success stories! ;-)

Since the patch only changes some header information but doesn't change the logic, I expect everything to work.

But in HTML context nearly anything can happen.

Please feel free to report any issues.

Best regards,

Ronald

[aked...@gmail.com]

Hello Ronald,
I am running into some odd nuances while testing where I seem to be able to run batches from my newly created user account but run into errors trying to select jobs that have already been submitted.

I set up the account like this using the SYSTEM password, the same way I set it up in the zope2 server:



I can submit batches and jobs run, but when I try to select a job that has already run whether it be successful/suspended/failed, or try to RIP a job I get the below error:



I don't know if it helps at all but I also see some odd greyed out checkboxes next to jobs that have run (could be nothing but thought I'd share just in case):



Any ideas?

Thank you again for all your help!
Andrew

[Ronald Jeninga]

Hi Andrew,

well, this has nothing to do with the original issue. Not directly at least.

Don't worry about those grayed boxes. The jobs shown seem to be final and you can't do anything with them any more.

If you have a list with active jobs those select-boxes can be selected. This way you can perform bulk operations (e.g. cancel, suspend or resume a whole list of batches at once, not one by one).

BUT, as far as I know, bulk operations are introduced in the 2.10 release.

And the error message shown (where the interesting part is actually missing and probably further to the right) is a next hint into this direction.

Do you by chance run a 2.10 GUI in combination with a 2.9 Server?

That won't work because the newer GUI expects things to work that aren't even implemented in the elder server.

So either you have to repeat the steps for a 2.9 SDMS.zexp (import it), or you have to upgrade your scheduling server to 2.10.

In the meantime I've checked in the change (Content-type) into git for 2.9, 2.10 and the current development release.

If, of course, you prove me wrong, I'll have to take a closer look at what's going on.

Best regards,

Ronald

[aked...@gmail.com]

Ah I was thinking that might be the case, I'll see what I can do :)

Thanks!
Andrew

[aked...@gmail.com]

Hello Ronald,
This can wait till Monday, but just wanted to report back that I tried a few things this morning and haven't had any luck.

I redownloaded and imported the SDMS.zerp file from the v2.9 branch: https://github.com/schedulix/schedulix/blob/v2.9/zope4/import/SDMS.zexp
This one seems to have the 2.10 components in it causing the earlier failures.

I also tried reimporting the .zexp that we used for 2.9 with Zope but that had it's own failures probably just from mixing Zope versions but I wanted to try haha.

Is the SDMS.zexp file in the v2.9 branch intended to work with 2.9? Just wanted to check before I resort to an upgrade to 2.10 :)

Hope you had a great weekend!

Thank you,
Andrew

[Ronald Jeninga]

Hi Andrew,

this is somewhat mysterious to me.

Obviously Zope2 Code can't be loaded into Zope5 because one runs with Python2 the other with Python3.

But basically the logic is equal.

What I did is to compare both SDMS folders and apart from differences caused by the language (2 vs 3), the rest was equal or semantically equal.

Can you please send me the FULL error message you get?

In case of a syntax error, the problematic part ist marked with +++++, like in

CONNECT 'SYSTEM' IDENTIFIED BY '**********' WITH PROTOCOL = PYTHON, TIMEOUT = 60, SESSION = 'BICsuite!web[localhost:8090]',

COMMAND = (show syntax+++++ error ); Syntax Error: expected COMMENT, CONDENSED, DISTRIBUTION, ENVIRONMENT, EVENT, EXIT_STATUS_DEFINITION, EXIT_STATUS_MAPPING, EXIT_STATUS_PROFILE,

/* SNIP */

Obviously there is not such a command like "show syntax error" and the parser marks syntax as the token it didn't expect.

(But in a way, the command worked; the server did exactly what I wanted it to do ;)

The part of the statement that you've posted looked OK, as far as I could read it.

And the problem occurs a bit more to the right, which is cut off in the screenshot.

And if I have a wish left, please just post the text, not the picture. (I can't copy and paste from a picture and I'm a bit too lazy to do all the typing).

Best regards,

Ronald

[Ronald Jeninga]

Hi Ańdrew,

I've discovered a tiny but essential difference (which doesn't look very harmful in a diff output)!

If you open

SDMS/SDMSDesigner/Jobs/AuditTypes

you'll find 3 Lists of operations (i.e. their names).

In the first list the last entry is "CLONE". If you remove that entry, things should work.

Best regards,

Ronald

[aked...@gmail.com]

Hello Ronald,
Thanks for taking a look! I made the change but I still see the failure unfortunately.

The full error text is:

show job 14554507
with
    FILTER = (RERUN RECURSIVE,CANCEL,RERUN,SUSPEND,RESUME,SET STATUS,SET EXIT STATUS,IGNORE DEPENDENCY,IGNORE DEPENDENCY RECURSIVE,IGNORE RESOURCE,KILL,COMMENT,CHANGE PRIORITY,RENICE,IGNORE NAMED RESOURCE,CLEAR WARNING,SET PARAMETERS,DISABLE,ENABLE,TRIGGER FAILURE,RESTARTABLE,JOB IN ERROR,SET WARNING,UNREACHABLE)

Error executing command
    ERRORCODE ...: 01111281413
    ERRORMESSAGE : CONNECT 'SYSTEM' IDENTIFIED BY '**********' WITH PROTOCOL = PYTHON, TIMEOUT = 60, SESSION = 'schedulix!web[schedulix-non-prod.mdm.idexx.com:8080]', COMMAND = (show job 14554507
with
    FILTER = (RERUN RECURSIVE,CANCEL,RERUN,SUSPEND,RESUME,SET STATUS,SET EXIT STATUS,IGNORE DEPENDENCY,IGNORE DEPENDENCY RECURSIVE,IGNORE RESOURCE,KILL,COMMENT,CHANGE PRIORITY,RENICE,IGNORE NAMED RESOURCE,CLEAR WARNING,SET PARAMETERS,DISABLE,ENABLE+++++,TRIGGER FAILURE,RESTARTABLE,JOB IN ERROR,SET WARNING,UNREACHABLE)

);
Syntax Error: expected CANCEL,
CHANGE,
CLEAR,
COMMENT,
DISABLE,
IGNORE,
IGNORE_DEPENDENCY,
JOB,
KILL,
RENICE,
RERUN,
RESTARTABLE,
RESUME,
SET,
SUBMIT,
SUSPEND,
TIMEOUT,
TRIGGER,
UNREACHABLE
REFRESH_DATA_ERROR



This is what I have in the SDMS/SDMSDesigner/Jobs/AuditTypes file:
return [
{ 'NAME'    : 'OPERATOR_ACTION',
  'LABEL'   : 'Operator Action',
  'DEFAULT' : 'true',
  'FILTERS' : [ 'RERUN RECURSIVE',
                'CANCEL',
                'RERUN',
                'SUSPEND',
                'RESUME',
                'SET STATUS',
                'SET EXIT STATUS',
                'IGNORE DEPENDENCY',
                'IGNORE DEPENDENCY RECURSIVE',
                'IGNORE RESOURCE',
                'KILL',
                'COMMENT',
                'CHANGE PRIORITY',
                'RENICE',
                'IGNORE NAMED RESOURCE',
                'CLEAR WARNING',
                'SET PARAMETERS',
                'DISABLE',
                'ENABLE'
              ]
},
{ 'NAME'    : 'RUNTIME_EXCEPTION',
  'LABEL'   : 'Runtime Exceptions',
  'DEFAULT' : 'true',
  'FILTERS' : [ 'TRIGGER FAILURE',
                'RESTARTABLE',
                'JOB IN ERROR',
                'SET WARNING',
                'UNREACHABLE'
              ]
},
{ 'NAME'    : 'RUNTIME_INFO',
  'LABEL'   : 'Runtime Info',
  'DEFAULT' : 'false',
  'FILTERS' : [ 'SUBMIT',
                'TRIGGER SUBMIT',
                'SUBMIT SUSPEND',
                'TIMEOUT',
                'SET RESOURCE STATUS'
              ]
}
]

In case it helps, the error pops up when I click on any batch that is part of a batch that was submitted (whether they succeeded, failed, or are suspended):
I see at the top that there are some new UI buttons too.



Compared to when I spin up the old zope UI:


Thank you again! 
Andrew

[Ronald Jeninga]

Hi Andrew,

well, apparently it doesn't like the ENABLE too. So please remove that too from the list.

I don't know exactly how those operations slipped in into that file (possibly a mistake while some backporting a bugfix), but let's get rid of them anyway.

The button row should be equal for both the Zope2 and Zope4 implementation.

What does it report if you click the i-button in the main menu? 

Best regards,

Ronald

[aked...@gmail.com]

Hi Ronald,
Removing enable fixed the errors! I can go into the submitted batches now and take actions like rerun, RIP, resume, and suspend without failures. The additional buttons at the top seem disconnected so at least they don't error if someone clicks on them :)

This is what I see when I click the i-button:


Thank you!
Andrew

[Ronald Jeninga]

Hi Andrew,

I've been thinking a little and it occurred to me that 2.9 was a kind of special release.

Special in the sense that we added some features after releasing it. (I desperately needed those features in some project I was doing).

More specifically the bulk operations and the enable/disable functionality was added. None of those features required a schema change, which made updating a 2.9 server risk-free.

So my guess is that the scheduling server you run is pretty ancient, not yet containing the mentioned new features.

The current 2.9 does have all those features. Hence the ENABLE and the buttons. (CLONE is not included; this was indeed a bug).

With the disable and enable operations you can comment out and un-comment  jobs also after submitting a batch.

In release 2.10 we've enhanced it even further and the enable/disable of a job can be driven by an interval (time schedule) and/or a condition.

If you, for example, have a batch with Jobs A -> B -> C -> D -> E and C should only run at weekdays, you don't need to make a copy of that batch to exclude C on weekends any more.

You simply attach an interval that selects the weekdays and use that to enable C at weekdays (in the job definition).

The clone operation in 2.10 addresses another issue in practice.

If you have a jobstream like the one above (ABCDE) and C runs into a failure, the cause of that failure can be B.

Rerunning C does not make sense; with identical input it will behave identically.

With the clone operation you can now clone B and run it again, although it is already final. (You should fix the underlying cause of the issue first, of course).

After that, you can rerun C (and it will even wait for the B-clone until it reaches a final state).

OK, after this short introduction of some of the 2.10 features, back to your issue.

If my diagnosis that your scheduling server is pretty old applies, you have three options:

1. Update your sandbox, build a new 2.9 and deploy it

2. Upgrade to 2.10

3. Leave everything as is and perhaps upgrade to 2.10 at a later, more convenient, time

Best regards,

Ronald

[aked...@gmail.com]

Thanks Ronald,
This is immensely helpful! We will plan to go with option 3 for now just because of current time constraints. We ran into only one more error today that I was curious if you have any insight into. 

When we click on a hierarchy we get the below Zope Error:

ZOPE ERROR
Zope has encountered an error while publishing this resource.
Error Type: KeyError
Error Value: Alert

This resource may be trying to reference a nonexistent object or variable ALERT.
The URL may be incorrect.
The parameters passed to this resource may be incorrect.
A resource this this resource relies on may be encountering an error.

Thank you again,
Andrew

[Ronald Jeninga]

Hi Andrew,

it seems that the battery of your luck-device needs a replacement ;-)

Anyway, can you send me the stack trace? That'll help me pinpointing the cause faster.

If you open the Zope management GUI, you'll find an item called error_log

If you click on that, you should see a list of exceptions that occurred.

Now click on the one that matches your error and Zope will show a page with detailed information, including a stack trace.

Just copy and paste it. No need for pictures.

And when you're at it, can you send me the build-hash of your schedulix server?

You can find it in the server's log file; it is written at server startup.

Something like

schedulix@oncilla:~/log$ grep Build *.out.*
BICserver.out.2966:INFO    [main] 06 Nov 2023 10:17:44 GMT Build-Date : 02.11.2023 16:14
BICserver.out.2966:INFO    [main] 06 Nov 2023 10:17:44 GMT Build : 6dc06934cd5d3295cafc26e17b7eb6c19d326ea6

Alternatively you can find it in the Manifest within the jar file:

schedulix@oncilla:~/bicsuite/lib$ jar xf BICsuite.jar META-INF/MANIFEST.MF && grep Build META-INF/MANIFEST.MF && rm -rf META-INF
Build-Date: 02.11.2023 16:14
Build: 6dc06934cd5d3295cafc26e17b7eb6c19d326ea6

Best regards,

Ronald

[aked...@gmail.com]

Thanks Ronald,
I totally agree haha. On the side I am thinking next steps and what it would take to upgrade in the future from this version. 

Seems like I'd have to get it caught up to 2.9 latest build and then I could go from there but I'm not sure if there is a clear path to 2.9 latest. 

Something we can tackle another day though :-)

For now I have the requested the information below:

Traceback:
Traceback (innermost last):
  Module ZPublisher.WSGIPublisher, line 181, in transaction_pubevents
  Module ZPublisher.WSGIPublisher, line 391, in publish_module
  Module ZPublisher.WSGIPublisher, line 285, in publish
  Module ZPublisher.mapply, line 98, in mapply
  Module ZPublisher.WSGIPublisher, line 68, in call_object
  Module Shared.DC.Scripts.Bindings, line 333, in __call__
  Module Shared.DC.Scripts.Bindings, line 370, in _bindAndExec
  Module Products.PythonScripts.PythonScript, line 338, in _exec
  Module script, line 1, in NavigatorDisplayPage
   - <PythonScript at /SDMS/NavigatorDisplayPage used for /SDMS/SDMSDesigner/JobHierarchy>
   - Line 1
  Module Shared.DC.Scripts.Bindings, line 333, in __call__
  Module Shared.DC.Scripts.Bindings, line 370, in _bindAndExec
  Module Products.PythonScripts.PythonScript, line 338, in _exec
  Module script, line 404, in DefaultNavigatorDisplay
   - <PythonScript at /SDMS/Common/Pages/DefaultNavigatorDisplay>
   - Line 404
  Module Shared.DC.Scripts.Bindings, line 333, in __call__
  Module Shared.DC.Scripts.Bindings, line 370, in _bindAndExec
  Module Products.PythonScripts.PythonScript, line 338, in _exec
  Module script, line 53, in RenderNavigatorLine
   - <PythonScript at /SDMS/SDMSDesigner/JobHierarchy/RenderNavigatorLine used for /SDMS/Common/Pages>
   - Line 53
  Module AccessControl.ZopeGuards, line 96, in guarded_getitem
  Module ZPublisher.HTTPRequest, line 1106, in __getitem__
KeyError: 'ALERT'



And here is the build hash:
BICserver.out.26:INFO    [main]         01 Nov 2023 05:04:51 GMT Build-Date : 30.05.2019 14:35
BICserver.out.26:INFO    [main]         01 Nov 2023 05:04:51 GMT Build : 2b4f63ebe0cf6689d05c8c4426bb443173680076

Thanks again for all the help!

Andrew

[Ronald Jeninga]

Hi Andrew,

that helped. Thank you!

As it turns out, the initialization of the value seems to be missing.

Again a one-liner which you can fix yourself easily.

If you navigate to SDMS->SDMSDesigner->JobHierarchy you'll find a script called NavigatorTransformTable

You open this and near line 530 you'll find the following code:

...

 if alert == 1:
     html = html + context.Common.Render.Alert('Cyclic dependencies detected')
 REQUEST.set('ALERT_DICT', alert_dict)

...

you now add one line and it'll then look like

 if alert == 1:
     html = html + context.Common.Render.Alert('Cyclic dependencies detected')
 REQUEST.set('ALERT_DICT', alert_dict)
 REQUEST.set('ALERT', alert)

And that should do the trick.

Updating your server to the latest 2.9 is pretty easy.

It all depends a little on how you started in the first place.

You don't seem to have set up your system from rpms, so you've probably compiled it yourself.

Now if you still have your sandbox and you are on brach v2.9, you only have to update it (git update), set your SDMSHOME environment variable and do a make.

If you've thrown away your sandbox, you can simply clone the github repository (git clone https://github.com/schedulix/schedulix.git -b v2.9), set SDMSHOME and do a make.

One result of the make is the BICsuite.jar file in the lib directory.

Now you shut doen your schedulix server, replace the old jar with the new one and start it again.

That's all.

Best regards,

Ronald

[aked...@gmail.com]

Hello Ronald,
Thanks for the help!

I implemented the change and got the below traceback for an error trying to view the hierarchy:
Traceback (innermost last): Module ZPublisher.WSGIPublisher, line 181, in transaction_pubevents Module ZPublisher.WSGIPublisher, line 391, in publish_module Module ZPublisher.WSGIPublisher, line 285, in publish Module ZPublisher.mapply, line 98, in mapply Module ZPublisher.WSGIPublisher, line 68, in call_object Module Shared.DC.Scripts.Bindings, line 333, in __call__ Module Shared.DC.Scripts.Bindings, line 370, in _bindAndExec Module Products.PythonScripts.PythonScript, line 338, in _exec Module script, line 1, in NavigatorDisplayPage - <PythonScript at /SDMS/NavigatorDisplayPage used for /SDMS/SDMSDesigner/JobHierarchy> - Line 1 Module Shared.DC.Scripts.Bindings, line 333, in __call__ Module Shared.DC.Scripts.Bindings, line 370, in _bindAndExec Module Products.PythonScripts.PythonScript, line 338, in _exec Module script, line 404, in DefaultNavigatorDisplay - <PythonScript at /SDMS/Common/Pages/DefaultNavigatorDisplay> - Line 404 Module Shared.DC.Scripts.Bindings, line 333, in __call__ Module Shared.DC.Scripts.Bindings, line 370, in _bindAndExec Module Products.PythonScripts.PythonScript, line 338, in _exec Module script, line 103, in RenderNavigatorLine - <PythonScript at /SDMS/SDMSDesigner/JobHierarchy/RenderNavigatorLine used for /SDMS/Common/Pages> - Line 103 AttributeError: 'dict' object has no attribute 'has_key'


When I googled it, it said has_key was removed in python 3 and we could replace with 'in' so I updated the code in  /SDMS/SDMSDesigner/JobHierarchy/RenderNavigatorLine line 103
From:

path = ''
if ROW.has_key('CYCLE_PATH'):
path = 'path'

To:
path = ''
if 'CYCLE_PATH' in ROW:
path = 'path'

That seemed to do the trick :-) 

Glad to hear the upgrade shouldn't be too bad either! Thanks again for all your help!

Andrew

[Ronald Jeninga]

Hi Andrew,

thank you for catching this as well.

If you want I can do the 2.9 compile for you (if you use Java 8) and send you the link where you can download the jar file.

You help me, I help you.

Ronald

[aked...@gmail.com]

Hello Ronald,
That would be a huge help! We are on Java 8 so if you find some time (no rush) that would be greatly appreciated.

Thanks again!
Andrew

[aked...@gmail.com]

Hello Ronald,
Hope you are enjoying the Holidays!

We had one small other finding that I debugged and fixed and just wanted to report back. The error popped up when trying to click the plus sign when displaying a hierarchy 


Error:

"'in' requires string as left operand, not int"

Solution:
in SDMS  / SDMSDesigner  / JobHierarchy  / RenderNavigatorLine
on line 109 and 125, wrap the id in str():
if str(nl1) in td and (('EXPAND_ID' in REQUEST and REQUEST['EXPAND_ID'] == '0' and REQUEST['EXPAND_TYPE'] == 'E') or str(id) in expandStateSave):

Thank you,
Andrew

[Ronald Jeninga]

Hello Andrew,

sorry for the late replay.

And I think this is awesome. Usually I only get a problem report here, not a solution.

I owe you a beer! (or some other beverage, whatever you prefer). Please remind me the next time we meet.

And since I'm in the process of creating rpms anyway, I'll add your fix before publishing them.

Happy New Year!

Best regards,

Ronald