Question

Forms participants cannot start any processes unless the forms server they are logging into has enough participant licenses assigned

Forms

Updated November 8, 2015

asked on October 10, 2015 • Show version history

One of our customers has two Forms servers:

DMZ Forms Server (has Forms Portal)
Internal Forms Server (has participant licenses)

These two Forms servers are sharing the same database.

The internal forms server has the participant licenses assigned to it. This is so that their IT can go in and add participant licenses on that server. Those users will then log in through the DMZ server (since they are out in the field during most of the day).

Here is the issue: even though the participant users have been given permission to the business processes, they get a permissions error when they try to start that process... but only if they log in through the DMZ server. They can log in through the internal server and everything works fine. We tested this further and found that Forms participants are unable to perform any action if that Forms server has fewer participant licenses assigned to it than the number of participant users registered in the database. For example, if the Forms server has 7 participant licenses, but there are 8 participant users, the permissions of all participants get revoked. They can log in but can't do anything.

I'm not sure why Forms process permissions are so tightly coupled with licensing. The core Laserfiche system treats those concepts as completely separate.

Ultimately, the customer needs their staff (both named users and participants) to be able to access the same business processes both externally and internally, and they want this to work seamlessly, with the only difference being that the user enters a different URL. This design (or bug) throws a wrench in this requirement.

0 0

Replies

replied on October 12, 2015

Thanks for the response Pava.

The confusing part is that, if the number of assigned participants exceeds the total number of participant licenses on that Forms server, the participant users can still log in. This is the inconsistent part. Assume you did the following:

Assign repository named licenses to a Rio server
Create a bunch of repository named users
Take away the repository named licenses
Try to log in with a repository named user

You wouldn't even be able to log in. Whereas with Forms, it DOES let you log in -- you actually see your inbox tasks and everything, and can change your account details -- you just get a permissions error when you try to start a process (whereas the LF Server would give a licensing error).

In any case, I know I'm arguing for consistency, but the more I think about it the more I realize having participant licenses behave the same way as repository named users doesn't actually make sense. The reason is that Laserfiche Servers cannot share the same repository database. In other words, Laserfiche Servers have complete segregation, in the sense that a Laserfiche Server has sole ownership of the repositories registered on it; you can't log into a repository through two different LF Servers. Whereas that is not the case with Forms. If two Forms servers can share the same Forms database, then participant licensing should be handled at the License Manager/Directory Server level, and not the application level.

Before you think I'm crazy, hear me out: the way authenticated participant licensing is designed right now causes a lot of friction in enterprise deployments, where there are usually at least two Forms servers (one on the DMZ, usually a Forms Portal, and one or more inside the network). The only restriction of participant users is supposed to be that they are forms-only, and cannot log into the repositories. This normally works fine. But users want to be able to seamlessly use the application whether they are logging in through the DMZ Forms Server (when they are out on the field) or the internal Forms Server (when they are in the office). The current design makes this impossible.

2 0

replied on October 12, 2015

Hi Ege,

What you describe here is exactly how Forms licensing is set up to work. Authenticated Participants are configured and defined per individual Forms servers, so different Forms servers would have different lists. Just like repository named users, Server a doesn't actually know that the 'same' user on Server b is actually the same - it has no knowledge whatsoever of it. (In fact, the behavior of repository named users is a pretty good way to think about how authenticated participants work, just on the Forms server instead of Laserfiche Server).

The behavior you are describing of the login being denied if the number of assigned participant users exceeds the total numbed of allocated users on that server is also the same as everywhere else. If you have more directory named users assigned then allocated on LFDS, or repository named users assigned then allocated on an individual Laserfiche Server, the behavior will be exactly the same. Forms participant users follow the exact same behavioral scheme as the other types of users.

As far as permissions goes, that's not an accurate way to look at this. This isn't permissions in terms of 'can a user see x forms process', this is 'what type of functionality is this user licensed for'. To put it another way, this isn't 'does the user have rights to modify document x', it's 'is the user licensed to modify documents AT ALL' - basically, full vs. retrieval named user licenses. The whole point of authenticated participant licenses is to provide a cheaper alternative for users who only require certain functionality, so it wouldn't make sense to then allow that functionality without even the allocated license. This is not an issue with using full Laserfiche named users in Forms - perhaps this can be thought of as one of the pricing tradeoffs.

Regardless, everything you described both seems as it should be AND is consistent with how licensing is handled everywhere else. The one notable difference is that the Forms server - not the Laserfiche Server - is the primary item, but again that's similar to how Repository named users work.

1 0

replied on October 12, 2015

I agree with Ege. It would be much simpler to have it work the way Rio Named Users work across multiple servers. that is how I interpreted the licensing originally when I saw you could license multiple forms servers but quickly found out it did not work that way.

However, since that is not the case, my recommendation would be to ask Laserfiche to combine your licensing and just work off the DMZ server since your database is already taking on the external exposure anyway. When you do that you can have your public portal and all your authenticated participants all on the same license.

0 0

replied on November 8, 2015 • Show version history

I watched the What's New in Laserfiche 10 video, and it seems (correct me if I'm wrong, Justin) this will no longer be an issue in Directory Server 10, since all users, including Forms participants, will be managed from the Directory Server.

0 0

You are not allowed to follow up in this post.

Question

Question

Forms participants cannot start any processes unless the forms server they are logging into has enough participant licenses assigned

Replies

Sign in to reply to this post.