• State Not Answered
  • Replies 6 replies
  • Subscribers 102 subscribers
  • Views 492 views
  • Users 0 members are here
Options
Related

Enforcing reason to a product that has request propertiea

Kalle N.

From a user experience perspective I think it is very annoying that if I set some request properties to a service item and mark it to require freetext reason on request (ordertypereason) allows the user go all the way to submit a request before the system throws an error for Request Reason missing. So yes the user needs to give a reason before the request can be submitted, but it is only brought up after several clicks and even when prompting that the reason is missing, you have to press Edit and fill the field? 

Is there any Out-of-the-box way, that would require no process changes or front-end validation changes, to make the REASON to also appear on the same panel as the possible Request Properties (if there are mandatory request properties)? I was not able to find any setting to make this happen, but I do know several customization options to make this happen. 

  • 0

    Create a request propert with the name "OrderReason", immediately write the supplied value back to ShoppingCartItem/PersonWantsOrg, and have it validate not empty?

  • 0 in reply to Ben

    Thanks Ben, but creating the parameter value to the PersonWantsOrg.OrderReason would require customization, no?  As I wrote in my last sentence, I know several ways to make this work with a bit of customization so that is not the issue, but as we have the option to OoTB enforce reason directly on service items / categories by OrderTypeReason, I was hoping this post would generate an enhancement proposal for future versions. 

    Also as I have different parameter sets in use, the model would require I add the OrderReason parameter to each of these steps. And as there are also requestables that have no parameter sets that are actually using the OrderTypeReason, I would not like to bring in a second "how-to enforce reason" scenario for the operations. 

  • 0 in reply to Kalle N.

    Yeah, so that suggestion only works if implemented in every modern request properties.

    What version are you on? There have been quiet a few enhancements with the ApiServer and Request Properties over recent versions...

  • 0 in reply to Ben

    This is now 9.2.2. Due to upgrade to newer version (probably first 9.3 before 10) later this year. I tested this in v10 environment and it still works the same way. I mean this is not a big thing to implement, but in my eyes it is a very common use case to require a reason and as there is the option to set either freetext or standard reason mandatory, it would be great if that reason setting would also pop up in to the side panel when adding a product to cart. 

  • 0 in reply to Kalle N.

    But actually reading this similar topic:  Reason as parameter in request properties (new definition) it should automatically set it to the PWO if the name is just OrderReason? That I did not know and I need to test if that works in 9.2.2. Still annoying that we need to have these additional mechanisms but at least it would not require tweaks in the backend.

    EDIT: Tested and unfortunately it did not work without without tweaking a bit in the backend.

  • 0 in reply to Kalle N.

    Yeah, we had even worse issues trying to handle ValidFrom/ValidUntil due to various client requirements (including hour limited requests - which appears to be a better option in v10 now on the AccProduct).

    When we started playing with using Modern Request Properties (v9.0) to override the OOTB ones (Reason, From, Until, Prolongate), we noticed it seemed to display fine on the initial request CDR with single entries, but in the cart or approval they were duplicated with the OOTB references. One of the approaches was to forcefully write the value directly to the respective table using the onChange script.