So then I get a response from him with a dozen lines of code.
Dev: If the DvB table is not found in the shared app directory (inside the program folder structure) then Program4-Sub-Print looks for DvOld. If DvB is present, then Sub-Print uses DvC. If Sub-Print is using DvOld, then it isn't finding DvB.
Hmm. He doesn't get it. :Popcorn: :hulk:
Me:
I understand from your explanation how the Sub-Print touches all three sets of the various login tables.
It's unexpected, and it doesn't make sense as to why, and it didn't happen in prior versions to the point where there were problems.
Based on your information in (the developer escalation owned by my coworker), we told the customer to rename their DvB files.
It didn't fix their error due to the DvOld files being zero-sized and resulted in the missing file error.
Easy enough to replace the those tables with blank/default login tables.
However, that also doesn't answer (my escalation).
If I use a prior version of the Program4-Sub-Print with the current/street Program4, and use all three of the customer's login tables, there is nothing preventing me from correctly accessing the Sub-Print program's functions.
If I use the current version of Program4-Sub-Print and remove DvC, Program4 creates new copies immediately upon opening the program. Upon inspection these files include identical information to those located in the DvOld tables. However, I still am unable to utilize the customer's login name (which is listed in the DvB under the shared folder structure) and use the Sub-Print.
Further testing:
(screenshot of the identical information between DvOld and DvB)
As you can see, the (shared folder structure\DvB login file) has identical information to (Program4 folder structure\DvOld login file).
I compared these to the (shared folder structure\DvC login file) table.
Between the two different tables we have:
DvB table has 8 unique values
DvC table has 4 unique values
There are 7 values in common with both tables
When I try to log in to Program4 using the unique logins from the Program4's DvC table, there is no Sub-Print functionality, as per (my escalations') "grayed out" option buttons.
When I try to log into Program4 using the logins from the DvB table, the Sub-Print works fine.
When I try to log into Program4 using the logins that are common to both tables, the following occurs:
Logins from the DvB all are able to access the Program4-Sub-Print correctly.
Login D, which is a security-level in both files (to allow for general use) is getting the inability to edit progrma options depicted by the grayed out button. This is expected behavior.
Login M, which is a security-level 1 (view only user) in the (shared folder structure\DvC), is bizarrely a senior user in the (shared folder structure\DvB) and (Program4 structure\DvOld) files. While this is an unusual configuration (I can't even figure out how they would have managed this) the user login into Program4 prevents them from adding information but has full capabilities to print. This is NOT expected behavior.
Circling back around to the DvC's logins which don't work - Why don't they?
Ostensibly from this testing, it's because they, for some reason, are not listed in the (Program4 structure\DvOld) file, and thus not listed in the (shared folder\DvB) file.
Additionally, each of the respective users (missing from the DvB and DvOld) are senior level, but per your explanation, since the Sub-Print is sticking its fingers into the peanut butter jar that is (shared folder\DvB), it's not seeing those logins and assumes "worse than view-only user".
So there's the explanation for the problem…
But how do we fix (coworker's escalation)?
Removing the shared\DvB tables will cause Program4 to recreate them - incorrectly, in this case.
Removing the Program4\DvOld tables will cause missing file error, because the Sub-Print needs them and Program4 won't recreate blanks/default value files.
So instead we need to remove the shared\DvB tables AND replace the Program4DvOld with blank/default copies.
Is this ideal?
No, but yes
Yes - Because the Sub-Print does not find, for example, login S in Shared\DvB or Program4\DvOld, it defaults to the permissions which had been assigned to the user upon Program4 login.
No - because removing the previously existing user logins affects the the primary Program1 and any Program2 and Program3 programs prior to 2008.
Circling back up to testing logins, this time with the Program4-Sub-Print the version from December 2014.
I have reverted the Shared\DvB and Program4\DvOld to the customer's files submitted for (my escalation).
Login M, which is a security-level 1 (view only user) in the Shared\DvC, and a senior user in the Shared\DvB and Program4\DvOld files. When printing, the (print options) button is gray and trying to edit the options returns the "You must be a senior level user." This is expected behavior for the user login security level "view only".
Login D, which is a security-level in both files (to allow general user) is getting the inability to edit program options and the grayed out button. This is expected behavior for user login security level "general".
Logins from DvB all still senior level, when printing, function normally and are able to edit Sub-Print options. This is expected behavior for user login security level senior user.
Thus…
There's a bug.
It can go one of two ways.
Either:
The Program4-Sub-Print was always intended to pick secondary login permissions from Shared\DvB, which in prior versions it had not, and up until version released May 2016 no one ever noticed. Now that it does, it does not recognize user permissions that are not present in the Shared\DvB file and thus "drops" the permission, resulting in (my escalation's) error of "You must be a senior user".
Or:
The Program4-Sub-Print ignored the Shared\DvB table up until the 5/2016 release, and something was changed to force it to / "fixed" to cause it to now look at Shared\DvB. Now that it does, it does not recognize user permissions that are not present in the Shared\DvB file and thus "drops" the permission, resulting in (my escalation's) error of "You must be a senior user".
The overall fix:
Repair the bug.
Either: Put Program4-Sub-Print back to the way it was prior to this release
Or: Do something additional* to cause the Program4-Sub-Print to better differentiate the user login tables so that user login permissions carry over from Shared\DvC when they are also not listed in Shared\DvB.
*Do something additional = that will not modify, edit, or break the existing respective login tables.
About an hour and a half later I get
Dev: A bug ticket has been entered for this issue.
:banana:
