I am working on a multi-member LLC operating agreement. In a multi-member LLC you can have either a single manager or a board of managers. I have a concept for #manager and want the label to be manager if there is only one manager and the label to be board of managers if there is more than one manager. As part of the questionnaire, I use repeated list variables to gather information about the members of the LLC including a true/false variable for manager status.
I would like to set up a change-set for the label of my concept to be such that “manager” is listed if there is only one “true” answer for my true/false variable or “board of managers” if there is more than one “true” answer for my true/false variable. I am having trouble seeing a way to do so. I don’t see a way to set up such a condition. Do you have any suggestions?
(My crude work around is just adding a question for “Will there be more than 1 manager?” but I would like it if I could eliminate this extra question.)
Wonderful question. It illustrates how quickly fairly simple legal questions turn into complex technical conditions, that are close to actual programming. So don’t feel bad that you were scratching your head, this is a simple question with an answer that is quite involved. By the way, dealing with repeating-lists easily triggers this complexity, because you then inherently work at a level “deeper” than with simple values (such as a text, number or date value).
Essentially, those expressions conditions allow you to specify more complex conditions for questions/cards/changes than you can achieve with the standard “visual” conditions in the Q&A editor. Those expressions conditions also have their limits — at some point you will need to revert to the embedded programming language — but you can get quite far with them, and for an advanced user like you, they should come across as reasonably familiar, because they essentially use the same syntax for question/card/change conditions as the conditions within the body of clauses.
Make sure that your question regarding the manager’s information (repeated list) has an identifier in Question options > Identifier. For example, I give it identifier “manager-info”.
In the Change condition for the plural concept-label, add the following expression condition. (I assume that the default concept-label is in singular, and does not get its own condition, i.e. the plural concept-label is the exception that should only apply in a certain condition).
This seems fairly complex at first sight, so let’s break it down, from the middle to outwards, because that’s also how such “nested” special functions are analysed by Clause9.
First you take the answer to the (repeating-list) question with identifier “manager-info”, more specifically for column “status”. As you can read in the help-page regarding expressions conditions, you can use @answer with two different parameters (in our case “manager-info” and “status”) when you are dealing with a repeating-list datafield. This allows you to target a specific part of a repeating-list value.
Next, you filter all those values (read more about it here: Special functions – Help), so you only keep those answers that have value “true” assigned to them. In other words, from the list of values that is extracted by the @answer special-function, you remove those values for which the checkbox is not activated by the end-user.
Next, you count how many values are kept after the filtering operation has been performed, through the @count special function, i.e. how many elements within the box “status” have a “true” value.
Finally, you compare that number of values, so that the condition for enabling the plural concept-label only applies when you are dealing with more than one “true” value assigned.
Maarten, the complexity with which Clausebase can be programmed is really impressive, but equally impressive are your quick and thorough responses. Thank you for providing clear, detailed answers like this. It’s so helpful.
I’m not nearly as well versed in Clausebase programming as Elmer is, so he can speak for himself as to whether you answered his question, but I think you did. I wonder, though, if there would be another approach to this that Clausebase could also handle, which would work a bit better from my standpoint.
As Elmer posed the question to you, the questionnaire would take in all of the entity owner information (using a repeated variable), and one of the questions asked about each owner would be whether he or she is also a manager. The premise of that approach, however, is that the set of managers will always be a subset of the owners. This is often true, but not always; an “outside” or “independent” manager might not be an owner at all, in which case he or she would not be selectable from within the owner repeated variable.
My alternative vision is that when it comes time to identify and collect information about the manager(s), the user could simply keep adding managers using the “+add” button and for each, the user would have the choice of selecting either one of the owners previously specified or one or more “others” and in the latter case, be able to fill in the information relating to the “other.”
I feel pretty confident that Clausebase would have a way to use information previously entered for a repeating datafield in a Q&A to populate subsequent choices for another datafield in the Q&A; could you outline how one would approach that? Elmer’s question about how to apply a change set for the #manager label based on how many managers are defined would apply in this context as well; I imagine the answer would be similar to what you’ve laid out here already.
Through the “…” next to a column (repeating-list) you can go to the “Predefines” box. There, you can either insert a placeholder (in curly braces), or a question-identifier.
That question-identifier option allows you to take the answers of some other question, and use them as a popup-list. See Global placeholders – Help for some more explanations.
If you would have a first table with the owners (and you add identifier “status” to the second field, which you then insert into the “predefines” of the managers table), then this would for example result in the following:
When you would select “alpha”, that value will then be copied into the input box of the managers.
It is possible to copy other data from the “owners” table, but that requires custom programming with the embedded programming language. (Essentially, you will need to match every relevant field of the owner’s table with every field of the managers table, and often some exceptions or slight modifications will need to be processed as well.) It can be done, but — as always with the embedded programming language — such code is more difficult to maintain, so you should reserve it to situations where it is really crucial for the end-user, and you are prepared to deal with the significantly higher maintenance cost.
As explained in my introduction towards Elmer, your questions are straightforward, but the implementation easily comes very close to traditional programming, because there are so many different combinations of how input boxes, buttons, and so on should interact with each other. Clause9 can get you quite far, but there are limits (such as copying values from one table to another upon some selection of an owner). Across the world, hundreds of thousands programmers spend their days custom-developing user-interfaces for enterprise software to deal with the often subtle interaction requirements between user interface components.
Elmer and I chatted this morning. He is being pragmatic, by essentially using the Owner concept to track which Owners might also be Managers. That doesn’t provide for non-Owners being Managers, but since that is less common, we could address that in final editing in Word if need be. I’m trying not to be too perfectionistic!
At the same time, it seems “cleaner” to me somehow to track Owner information under the Owner concept, Manager information under the Manager concept, etc. I just wonder if we might run into situations down the road – ones that we don’t have the experience to currently anticipate – where taking these practical shortcuts today and avoiding more complex programming might handicap us in some way.
I suppose it’s in part a question of just how hard would it be to, in essence, migrate Owner data over to Manager datafields if/when a user indicates that a particular Owner is also a Manager.
Maybe we just do it the way that is easiest now, and if different use cases arise in the future where it would be extremely beneficial to have the independent concepts and datafields, we would address this at that time – even if it might involve some “retrofitting” or redoing of current work?
I’m not a programmer so I don’t have the experience of how to think about this… Appreciate your insights.
1. Nobody has a crystal ball — so you may curse the fact that it will turn out that you happen to now be taking the wrong path — but in programming circles there’s an important principle:
YAGNI
which is short for “You Aren’t Gonna Need It”
It’s a principle in programming that suggests you shouldn’t add functionality (or implement things that cost a lot of time and may or may not be necessary in the future) until it’s necessary. This prevents spending time on features or optimizations that might never be needed, allowing a focus on the current requirements. (A typical example is a startup who would build software & infrastructure as if they will have the scale of Facebook, instead of dealing with scaling issues if/when it arrives. This makes things much more difficult and expensive than taking the simpler approach and expecting normal scaling.)
In this case, it can become quite involved to do it in a very clean way, while the work that you would have to do at some later point if you happen to be wrong, will likely be reasonable. The YAGNI principle then dictates that you deal with it later. Remember, being lazy as a programmer is considered a good thing. (Really!)
2. In the context of document automation, cardinal sin #1 is trying to be too perfect. We see this all the time, with layouts too closely mimicking the original document; building in every possible legal variation you can think of; giving too many options; etc.
This can easily lead to situations where more than half of the time is spent on a few small things that do not really matter. If some things can be done easier in Word, then please do so.
Working on it… Thanks for the good advice. I will start using YAGNI as a mantra. But I would suggest the more colloquial phrasing, “You ain’t gonna need it.”
