June 17, 2010 at 10:24 pm #519
I have some fields that need to be in the normal state when the form is in the default stage, but hypothetically it could be any stage. I only want the field to be normal for a single user. When a person is starting any form, they come into the form with the role “unspecified”. How can I control how the state of objects for a user starting a form? I thought I had figured this out using the All/All stage/role combination, but now thats not working.June 23, 2010 at 9:37 am #5335
There are several ways to manage field states, there are no hard and fast rules.
A common method is to use the All Stages/All Roles combination to set a ‘standard’ rule which would often be the rule that restricts access to the field (Read-only, Hidden or Disabled) and then use specific Stage/Role combinations to manage the exceptions to the standard rule.
Use the ‘Default Stage/All Roles’ combination to control the state of objects for a user starting a form.
There is a hierarchy that applies to the stage role combinations so that specific stage and role combinations will override the ‘All stages/All roles’ combination.June 24, 2010 at 3:58 am #5338
Thats what I have been attemping –
“Use the ‘Default Stage/All Roles’ combination to control the state of objects for a user starting a form.”
But it is not working. Lets say I have a form with 4 stages and 4 roles (A Submitter and 3 approvers). If I have fields that only the submitter should be able to change at the Submitter(default) stage, I only want the submitter to be able to make changes to the field at the submitter stage. However, if I go into a fields edit state window, and set the field to be read only for all roles at that default stage except the submitter, how can i make the field editable by the starter, since the default role is “unspecified”? The only time now that I have been able to get a field in the normal state for unspecified is if a “majority” of the roles see the field in the normal state at a given stage. I showed this to CJ earlier this week. What you are saying makes sense and seemed to work fine in 1.16, but since the upgrade I have not been able to make a field normal for both my submitter role and the default unspecified role at the default stage.June 24, 2010 at 8:47 am #5339
If you have a support ticket already started for this case then it is better to use that method to resolve the problem, especially if it looks to be version related rather than a ‘how do I do this’ type of question.
I do have a comment on the ‘Default’ stage issue though.(This is mainly for folks who want to understand this topic a little better rather than for any possible release related issues mentioned previously).
At the default stage (i.e. when the form instance is first opened/created) there are no roles defined (Roles are only defined when a notification is sent to someone, allocating them a role, and this only happens when the form has been submitted) so there is no point in trying to set any access rules for specific roles at the default stage.
Furthermore only one person can access a form instance at the default stage; it is the person who will create the instance (who would normally be considered as the submitter/requester/applicant etc.) so the ‘All Roles / Default Stage’ combination would only apply to this person who is creating and submitting the form instance.
The exception to this would be if your logic is such that you notify other users (thus allocating them roles) in a way that the form instance does not move to the next stage … this is the only way (that I can think of) that a person with a specified role can access a form at the default stage. Although technically possible it is an unlikely scenario in most processes, and does not apply the very first time the form instance is opened/created.June 24, 2010 at 3:05 pm #5340
Sorry, I originally started this post and wasn’t getting an immediate response so i submitted a ticket later on. I see your point on only one person being able to start a form so rights at the default stage shouldn’t matter for the rest of the roles, but each stage in our forms has a “reject” path that sends the form to the previous stage. So if a stage 2 user opens a form at stage 2 through an email link, and decides the submitter has forgotten to attach something or (and this is just me thinking maliciously) maybe they want to change something in the form, and they have figured out that their role has unlimited rights to change a form at the default stage. They could resubmit it if they reject it back to the default stage. They could open the link they received previously after they have rejected the form back to the submitter and before the submitter has gotten a chance to get into the form, make any changes, and resubmit the form. Now we have put things in place like a signature line that gets filled with the users name and date that clicks the submit button, and I would like to think that this is something that would be noticed fairly quickly. However, being a financial institution, it’s not something we feel comfortable leaving to chance, and seems like if we could just control a field state for “unspecified” and treat it like an individual role, that would solve our problem.June 24, 2010 at 3:26 pm #5341
I can see now how the option to have the ‘unspecified’ role available in the list alongside the ‘All’ roles would help in this particular instance.
I also appreciate that you found a way around it for your process but for the benefit of others who may be faced with the same, or a similar, issue they might consider creating a stage (perhaps called ‘returned for changes’ or ‘returned to submitter’) that the request is sent to if the stage 2 user decides that it has to go back to the submitter, (rather than sending it back to the default stage). The access rules can then be applied to this new stage so that only the submitter can make the changes.
Hope it helps.June 24, 2010 at 3:54 pm #5342
Lol I had hoped you wouldn’t suggest that. That was going to be my fall back if “unspecified” couldn’t be added to the list of roles. For now that will work, but would getting control of unspecified be possible in any near future releases?June 24, 2010 at 4:11 pm #5343
I can get it on the list for the reason you suggested and also another reason where it might be required.
If access to a form is provided via a link in a report then it is also possible for an unspecified user to open an instance. In such scenarios it may be useful to be able to manage the unspecified user.June 24, 2010 at 4:37 pm #5344
Thanks, you guys are awesome. This is hands down my favorite software to use right now :). Takes RAD to new heights.
You must be logged in to reply to this topic.