Presswise ES: Better handling of situations where a username already exists and is related also to another subscriber

We are still encountering this error on an infrequent basis. Prepending/appending the site's Integration ID to the username for the integration appears to be the quickest fix. This does not alter the username in Pressero, so there wouldn't be any confusion for our users when the try to log in. Additionally, since the integration only uses the user's Integration ID when injecting jobs, it really seems like the username in PressWise doesn't matter at all. It is required by SmartSoft, so when the account is created it needs to be supplied, but after that, Pressero doesn't use it.

Please consider changing the integration to prepend/append the site's Integration ID to the username supplied to PressWise when creating a new user. That should 100% solve this issue with a minimum of development time spent creating the solution.

What are your thoughts?

This continues to vex us. On average, I may only have 2-3/month that fail to inject due a duplicate username, but it is a real pain to correct. My initial suggestion to apprend/prepend the customer ID from the site setting to the username in PressWise seems like a sure-fire fix for this issue. The user could have duplicate usernames on different sites in Pressero and still not have a duplicate user ID in PressWise. This does not require modifying the username and risking that the user will just change it back at some point in the future causing the exact same issue.

This continues to be an issue. It requires several manual steps to get an order to inject whenever this occurs.

• Create a new user in PressWise under the correct customer. Typically I append a "2" to the end of the username that Pressero assigned to the user.

• Update the user in Pressero with the Integration ID created in the previous step.

• Push the order manually in Pressero.

That has worked every time for me, so far. However, many times I do NOT know that an order has failed to inject because we do not live in Pressero. The system notification, as it is currently designed, is a part of the problem. If the system notifications ONLY displayed errors, then it wouldn't be as big a deal. I could do my normal morning push from Pressero and then check the logs to see if there were any errors.

I do hope that Aleyant would agree that this is not an ideal workflow. We specifically chose Pressero because it had an excellent integration with PressWise. It has been mostly really great, but this is a huge pain point for us.

I was mistaken in my last post, using the email address, by itself, would still fail. My suggestion at the end is pretty much the solution, I believe.

Ah, I see "Presswise ES" at the beginning of the title, now. Not sure how I missed it previously.

I can't imagine a scenario where a Pressero user would ever need to know their login ID within PressWise. I'm not saying it couldn't happen, but if my user is "living" in Pressero, then why would they need to know anything about PressWise? We certainly don't expose PressWise to any of our Pressero users, but I suppose there could be a valid reason for that to happen.

It seems that the ultimate fix to this issue requires Aleyant and SmartSoft to make changes to their systems. For SmartSoft, they would need to alter their database schema to allow duplicate login IDs as long as they are attached to different customers. For Aleyant, you could simply use the user's email address as the login ID when creating the new account. If the user updates their email address, then of course the user would need to be updated in PressWise, as well. Email addresses are already unique within Pressero, per site, so no duplicates could be injected.

For a short term fix, the easiest may be that when Ayelant tries to create a user within PressWise and receives a duplicate user error, they simply add an incremental number to the end and try again until they succeed. That would ensure that no orders are prevented from being injected due to a duplicate user error.

Presswise ES is the integration name's on Pressero. Presswise Embedded Services.

If the username that is ultimately sent to PressWise is something that the end-user needs to be able to know and use in the future, long prefixes might be hard for the user to remember. A static prefix doesn't solve the problem either. If the user's full name is James A. Jones, the current logic assigns a username of jajones. With a prefix, that becomes prefix-jajones. As soon as Jane A Jones signs up, there will be a duplicate again. The prefix can't be static.

I see a couple options:

1. Add a new field in Pressero for an MIS ID that is always unique (could be the PK of the table for that matter) that is associated with the user ID. The integration could use the auto-assigned auto-inc ID as the userID that gets sent over to PressWise for user-creation. This would ensure that the username is always unique, but it provides a level of ambiguity on the resulting orders if there is any desire to lookup that user's orders in PressWise.

2. When the error of duplicate user is returned, auto-append an incrementing number and re-submit with the new username. For example when Jane A Jones signs up, you could create jajones_1, and then when John A Jones signs up, it would be user jajones_2. Those numbers could be bigger or be alphanumeric, but in any case, it would be creating a similar but new and unique username.

This doesn't mention the PressWise integration, specifically. That is where we are encountering an issue. I have only noticed one order that this has happened with on our installation.

It would be my hope that when injecting an order into PressWise, if Pressero encounters an error while creating a user because of duplicate user name, that it would append/preprend the integration ID for the PressWise customer. That seems like it would be an easy enough fix. It could even do that for every customer ID, and that should eliminate the possibility of a duplicate user ID being found.