openwebwork / webwork.maa.org

Information about the webwork.maa.org server
0 stars 0 forks source link

scrips in RT are not working (need another pair of eyes on this) #39

Closed mgage closed 4 years ago

mgage commented 4 years ago

These scrips [sic] define actions on receiving a transaction. Most common actions are to email the appropriate watchers, e.g. alert the Admincc's about an incoming course request. There are actions set in the database (carried over from the previous installation) but they are not firing. The immediate issue is trying to edit these action scrips from the web:

https://rt.webwork.maa.org/Admin/Scrips/ gives a list of scrips (choose the tab Admin->Scrips->Select Now click on say "On transaction and SetStarted Open Ticket" you get https://rt.webwork.maa.org/Admin/Queues/Scrip.html?id=19&Queue=0 and a page not found response. Scrip.html should almost surely be Scrips.html since that is the file found in the directory /opt/rt4/share/html/Admin/Queues

It seems strange that a bug like this would persist, if it is a bug. I haven't yet found a place where this configured and the configuration is misspelled.

mgage commented 4 years ago

I've found references to Scrip.html in RT_SiteConfig.pm and correcting that to Scrips.html fixes the error message. Still not able to edit the scrips however. Here is the snippet from RT_SiteConfig.pm

   Scrips =>
        q{'<a href="__WebPath__/Admin/Queues/Scrips.html?id=__id__&Queue=__QueueId__">__id__</a>/TITLE:#'}
        .q{,'<a href="__WebPath__/Admin/Queues/Scrips.html?id=__id__&Queue=__QueueId__">__Description__</a>/TITLE:Description'}
        .q{,__Stage__, __Condition__, __Action__, __Template__},

    GlobalScrips =>
        q{'<a href="__WebPath__/Admin/Global/Scrips.html?id=__id__">__id__</a>/TITLE:#'}
        .q{,'<a href="__WebPath__/Admin/Global/Scrips.html?id=__id__">__Description__</a>/TITLE:Description'}
        .q{,__Stage__, __Condition__, __Action__, __Template__},
taniwallach commented 4 years ago

https://docs.bestpractical.com/rt/4.4.1/UPGRADING-4.0.html mentions that RT_SiteConfig.pm needs careful review when upgrading from versions before RT 4.0.

mgage commented 4 years ago

Current blocker: https://rt.webwork.maa.org/Admin/Queues/Scrips.html?id=8&Queue= obtained from Admin->Global->Scrips->Select and clicking on script #8 The id is interpreted as a queue not the script.

mgage commented 4 years ago

This might be a database issue. The schema at https://rt-wiki.bestpractical.com/images/b/b5/Rt_schema.png doesn't match the current schema in our database. (obtained from https://rt-wiki.bestpractical.com/wiki/Schema )

Also at https://rt.webwork.maa.org/Admin/Tools/Configuration.html (Admin->Tools->System Configuration) near the bottom there is an indication that the upgrades from 4.04 to 4.4 didn't all go smoothly.

I'm not sure how to best recover from this.

pstaabp commented 4 years ago

Now that I can see everything, I'm trying to figure out how I can help. I don't think I have server access, or do I? Are there error logs for the upgrade process on the server that are available?

mgage commented 4 years ago

You do have server access with user name pstaab.

I worked on Glenn for a little bit this afternoon — we just finished. I think we are going to have to rebuild the database again from the dump I made on Feb 16.

We’ll try again tomorrow afternoon.

Take care,

Mike

On Mar 6, 2020, at 4:27 PM, Peter Staab notifications@github.com wrote:

Now that I can see everything, I'm trying to figure out how I can help. I don't think I have server access, or do I? Are there error logs for the upgrade process on the server that are available?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openwebwork_webwork.maa.org_issues_39-3Femail-5Fsource-3Dnotifications-26email-5Ftoken-3DAAJF27AYEK25RYGQ7QUXLYTRGFTEHA5CNFSM4LDA25TKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOC5C6A-23issuecomment-2D595972472&d=DwMCaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=C6Pt5AGtImanmAdcooarL-JZO8M5dSFPfs3VweYXYkE&m=N3IGK88CrpaYdyDrUl26o1iXWXj9_eJP4z5iT8lbjt0&s=0kd33ENXirCvYm6yKHhmSv7xAbELDzrTDy_Bnol78EM&e=, or unsubscribe https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AAJF27CN6VGDHF2TAPNIMPTRGFTEHANCNFSM4LDA25TA&d=DwMCaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=C6Pt5AGtImanmAdcooarL-JZO8M5dSFPfs3VweYXYkE&m=N3IGK88CrpaYdyDrUl26o1iXWXj9_eJP4z5iT8lbjt0&s=Mx8lO34eW5AEs2GtwP6yLwZgTMQKlqKts8yhur43Xj8&e=.

mgage commented 4 years ago

Glenn Rice and I rebuilt the database from 4.0.4 to 4.4.1 on Saturday. The scrips now seem to work as expected.

We still need to figure out how to utilize the capabilities of RT to manage our ticket requests. (Should it interact with bugzilla, with github issues?, ) Previously it managed setting up new courses on MAA servers, managed the database for the WeBWorK sites map and fielded alerts about the status of the MAA servers, request for lost passwords, (complaints about bugs in PG problems- these were supposed to be routed to the forums) and so forth. Now is a good time to make a plan for managing The WeBWorK Project and then figure out what role RT will play and learn how to configure it to satisfy our needs.