Hi Jeroen, thank you for posting your question. Have you tried to supply the correct filtering in the URI, and try to leave out the PK values in the message body. Let me know if this helps. for reference : https://docs.thinkwisesoftware.com/docs/indicium/api
Hi Sujit,If I understand you correctly your question has two parts:1. You want to know if you can assign a task to a view2. You want to know if this requires a synchronisation/model refresh. My answer: 1. Yes this is possible, it works the same way as assigning a task to a table through the detail tab under menu item 'tasks' called 'table tasks' (yes the name can be confusing so I understand your question)2. Yes this requires a synchronisation/model refresh. This is an update to the model so in a 'development' environment you'll need to press the 'Refresh model' button (in web and windows GUI), and in an IAM environment (e.g. test, acceptance or production), you should synchronize the model from the SF to the IAM database before you can refresh the model. After a model refresh you should see the changes.Also, if you are having trouble seeing the ‘assigned task’ make sure the checkbox 'Show’ is on in the list of assigned tasks under ‘User Interfase → Subjects → Default/Variant → Links →
Hi @Anne Buit , thank you for this post, very informative. Does EoSL mean that the runtime component will not be available anymore for download through the Thinkwise store?
Ik heb naar de huidige validaties en hier valt mij het volgende bij op:De 6 validaties bestaan uit 3 validaties op de main subject en 3 voor de subject varianten. Dit gaat over main subject, detail subject en lookup subject prefilters. Waar deze validaties controle op uitvoeren is of er een actieve prefilter aanwezig is als de prefilter group op 'mandatory’ staat. De reden dat het om een geel uitroepteken gaat ipv een rood kruis heeft m.i. te maken met dat je soms het juist bewust zo wilt inrichten als je bijvoorbeeld default een lijst leeg wilt tonen door alle verplichte prefilters op off te zetten maar niet op hidden zodat de gebruiker door de juiste prefilter te kiezen om de data te tonen. Maar mijn casus valt hier buiten omdat in mijn geval alle prefilters van de prefiltergroep op off en hidden stonden waardoor er nooit iets getoond kan worden in de desbetreffende tabel/view/variant. M.i. moet hier een ‘rode kruis’ controle voor komen omdat er geen scenario te bedenken is waarbij d
I agree with Roberts stand point on applying the same logic in context and task alike to enforce functional integrity independent of the way a task/procedure is called. In addition to allowing the same logic to be applied to the context and task there may be scenario's where you'll want to apply the same logic in the layout and default in case it's not obvious why a task is ‘disabled’ through context for example in cases that rerely happen in some businesses like when a customer has exceeded its credit limit which prohibits the user of the system to sell new items to this customer (e.g. execute task ‘add_sales_order_item’). By disabling this task it can be confusing for the user why the task can’t be executed. The user might spend unnecessary time figuring out why this is. I.m.o. instead its more user friendly to show a message to the user - before entering the task parameters and executing it - explaining that the customer has exceeded the credit limit. Obviously this has to be done t
Already have an account? Login
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
