Not sure I'm getting all of the issue in #1.
By design, in Footprints 12.XX - 20.XX, agents cannot be both customers and agents in the SAME workspace, that is simply impossible.
Now, if you create a new workspace from scratch, this needs to be defined in each agent's profile with a role.
This is exactly where you can decide if a user is actually going to be taken as an agent or as a customer, or any other role you like, in a particular workspace.
Therefore, when an email is received from an email address, if the email address the email originates from is found to be an existing user's, then Footprints first tries to check if the role is an agent or a customer one, and then we create the ticket.
If this doesn't work, then we have to inspect what is going on when the email is received by looking at the log closer.
#2 i indeed an existing and ongoing defect. We are still working on a solution so far.
1 of 1 people found this helpful
For issue #1, this is normal. A user who does not have a role in a container will not have access to that container. If someone was not a user before, just a contact, and now they are a user, they will need the appropriate roles in all containers they use.
For issue #2, that defect is still open.
Allow me to clarify a bit on #1.
If someone has an existing role anywhere else in Footprints, they cannot be a contact in this new workspace unless they have been assigned a role in that workspace. Incoming and outgoing email fails for these individuals. If I change their email address to something that isn't associated with anyone in Footprints, it falls back to the "default customer" role we have set up for all external contacts.
So if the logic would be for Footprints to only check the container role where, if there were no existing container role then treat it as an external contact, all would be fine.
That is normal. They can still be a contact, but you're right that incoming email will fail. Outgoing email should still work fine since it is based on their email address and the Portal Guest role. But incoming email would fail since the way it works is that it attempts to match the incoming email address to the address of a user (either customer or agent). If it matches, then it follows the permission from that user. In your case, that user does not have role access to the container, so therefore they don't have permission to update. In the event there is no user, then FootPrints will default to the configured 'Default User' configured user's role permissions in Incoming Email (Workspace) for that particular workspace.
So yes, the moment you create someone as a user in FootPrints (either as a customer or an agent) you need to ensure that user has permissions to every container they would interact with. If you need to bulk update existing users, I can provide you a SQL query that can 'export' your users in an importable format. You'll then need to tweak it to include the new role(s) and ensure the file is split and separate import packages created for each of your System Roles that you use.
Thanks for the offer, Nicolas. We were provided the queries and had successfully tested adding AD groups and using the LDAP import option for adjusting containers and roles. For future reference, in our tests outgoing email also failed.
The second issue with the defect is where we are stuck. I'm not sure we can take the risk of having a customer assigned to a ticket in any of our workspaces. I've been our FP administrator for 16 years now and we could usually either find a work around or live with the issues in the past. I'm not sure we can do that in this case. I'm a bit surprised this issue was identified two years ago and has yet to be addressed.
Yea defect discovery to resolution is a lot longer than I'd like. This particular defect I don't feel is a show stopper per se (although I'd agree it really doesn't look good on the vendor's part). The reason I say this is primarily for the reason that it only impacts agent users. Agents should always be trained to only assign tickets in the following:
- To another team
- To another agent, only in circumstances when there has been a warm transfer (ie: talked to that agent in particular)
Couple that with the fact that generally teams are fairly small and people know each other, the odds of an agent choosing a customer user are slim (IMO).
In your case you need to weigh the pros/cons of the upgrade (but with 16 years experience you know this all too well!)
And here you can also consider that round-robin is now a feature, so maybe that will 'workaround' this defect for you?