Grid application fails when hitting "add new" to open blank form

[mosterho]

First time entering an issue on the forum, so please bear with me.
I have an application that was working up until 2 weeks ago. I am using pretty basic applications in Scriptcase, hardly anything custom as far as PHP is concerned.

Normally, in a grid, the user can hit the “add new” button which would open a form to enter new employee information. Now when hitting “add new” I get a 404 error. We can click on an existing employee to change his/her info and get the same form, but “add new” button on this form give the same 404 error. When I hit “F12” for debugging, the debugging console says it can’t find the folder, but of course when I SSH to the application system console I can see the folder with full R/W/X rights.

The test system runs on apache, which works fine. The production site is on MS Azure which uses nginx.
Update: Currently using Scriptcase version 9.10.002 for development. I deploy to a release region that mimics the same folder structure as production. I then use SFTP to copy the 33,000 or so objects from release to nginx production.

[Kevin_Willis]

This sounds like a permissions issue - from the web server (NGINX’s) perspective.
You mentioned you’re hosting within the Azure cloudspace - have you received any notifications (within the the 2-week period) - that might provide more insight as to what may happened?

Any image, or two, may provide others her insight into your issue.

[mosterho]

Thanks Kevin. nginx forces everything into a “777” mode, or everything gets read/write/execute rights. I logged onto the console and confirmed this.

UPDATE: It looks like I have the same error while using the security module. I created a near exact duplicate of the original grid and corresponding automatically generated form, and added it to the menu, It appears there is no ability to insert rows on the grid. I opened the security module portion of my site, went to groups/applications and tried to allow INSERT and received the same 404 error.

Before:

After:

[mosterho]

Here’s a screen cap of the original issue.

Before (grid, which works fine and I can update an existing row):

After clicking on the first row to update a member, works fine (same form for an INSERT): If I click “add row” I receive the error both on the grid and this form

[Kevin_Willis]

When attempting to add a new grid row, what URL is being requested?

Have you tried deploying to a server instance with Apache as an application server (instead of NGINX)?
If so, do you experience the same issue?

[mosterho]

Just additional info: When using PHP on MS Azure it requires at least version 8 and nginx, so I can’t deploy to apache when using an Azure app service. The Ubuntu server in-house is PHP 7.4.3. When uploading folders and files, the rights are controlled by Azure (hence the “777” and nobody/nogroup entries).

The URL requested is in a menu. The grid opened is “grid_Roster”. The form used for insert/update/delete was generated automatically and is form_Roster. When updating roster data it opens the same form_Roster and works fine. I haven’t tried deleting production data (for obvious reasons).

My deployment goes as follows: After I finish my changes in Scriptcase I deploy to a “release” region on a Ubuntu server which uses apache. This server is a VMWare server on my in-house system. Everything works fine in the release region.

I then use Filezilla to SFTP all objects to MS Azure nginx for production. I recently deleted all 28,000 objects on both release and production Azure (just to ensure I have a clean slate) did a full deploy and then copied the objects from apache release to nginx production directly. The release and production folder structures are identical (/home/site/wwwroot).

At this point the only real differences I can think of (other than apache and nginx) are in the mysql database. Not sure if this is the cause of the same issue when trying to update the group/application security module info? I’m going to start looking into security module tables (sec_users, etc.) just to rule that out.

As always, thanks for your assistance!

[mosterho]

Thank you everyone who took the time to look at this. This is resolved, although I’m not sure what the original cause is.

Normally the security module is created in the “security” folder, apps begin with “app_” and the database tables begin with “sec_”.

I recreated the security module with folder “security2” apps now begin with “app2_” and the database tables begin with “sec2_”. Fortunately, I don’t have too many user profiles to recreate; they just have to change their passwords.

I kept the original “security” folder intact; maybe I’ll do some stare-and-compare at the tables at a later date.

Again, thanks to all who looked at this.