Hello,
BIG BROBLEM: When I had finished configuring at servertask, parameters that were deliberately set to "empty" are overwritten by parameters of the project, depending on how the project was parameterized locally.
Some parameters must be empty (see validation rule)
empty parameter at ServerTask was set local Projectparameter
bevore copying new Version it was empty
All Tasks with this configuration ar failing now - i have to "empty" parameter again
regards,
Adrian
It's even worse. Text parameters that have already been set are also overwritten with local parameters, so that the complete configuration has to be set again
Hi Adrian, we're urgently looking into this.
Hi Adrian,
We can't reproduce the problem. Please contact us at support@easymorph.com to arrange a call.
Hi Dmitry,
I still have a suspicion. It seems to affect all parameters that are set but hidden/deleted at server.
These are not really deleted, but only hidden.
Background:
We have a job that is very fine to configure. There are few configurations per parameter group.
I hide all parameters that are not needed in the group via "Delete".
Annotation:
The name of the button would probably be better Hide than Delete
Would you test that again? Otherwise, I prepare a test environment and we make an appointment.
This are our Groups: The Tasks configure just one Project:
regards,
Adrian
Hi Dmitry,
I made a less complex example to demonstrate. I guess it is just a misunderstanding of the meaning.
Test unassigned parameters.morph (2.8 KB)
We have two parameters in the project, but we delete one of them at the server:
In fact, the parameter is still in use.
Next step: I change the parameters in the project and publish to server again.
The parameter 'Count' is still 10, but the unassigned parameter has changed.
We have assumed that the unassigned parameter will not be adjusted, but the unassigned parameters will be reset to project standard.
The idea behind was to hide the less changing parameters by that way so that only the set of common parameters are shown.
As I tested it now, I guess that everything works fine, but we just have to assign all parameters we really need.
so, again ... this would be a nice Feature to have 
Registerpages could be
A few questions:
Hi Dmitry,
I think the server version before was 5.8.1.
Solution to the problem:
regards,
Adrian
Hi @rebmanna
It seems like there might be a misunderstanding about how EasyMorph Server tasks and workflows operate. Let me clarify to ensure we're on the same page: Is this behavior you're noticing new due to a server upgrade, or is it more likely that you only just encountered this issue?
Let me write how parameter values are calculated and how parameters function by design, and you can let me know if this aligns with your observations:
.morph file) can have one or more parameters..morph file, parameter values can be 'constants' (such as 'Text or Number', 'Date' parameters, etc.), and in these cases, the parameter values are what you set in the Desktop workflow designer using the 'Edit parameters' dialog. Alternatively, the parameter can be 'Calculated', where its value is determined by evaluating the formula it contains.morph-cmd, on Desktop, or Launcher - the parameter values are determined right before the Module itself is computed, during the initialization phase, so to say.On the Server, when a project (.morph file) is used to create and execute a Task, the process is exactly the same: the workflow computation is initiated, parameters are calculated following the logic above.
However, there's a key distinction with the Server, which might relate to your question. The Server allows you to select certain constant parameters (e.g., all except 'Calculated' ones) from the .morph project and override the default values of these parameters with the ones entered on the EasyMorph Server Web UI. In other words, with EasyMorph Server tasks, you specify 'I want to override these parameters', but not 'use only these parameters'. And, naturally, if you don't specify some parameters as overridden ('assigned') in the Task, they fall back to the standard evaluation routine described above, and this is by design.
Does this match the behavior you're seeing?
Hello Olysak,
thank you for the feedback. That's all clear so far.
The point is that in my opinion, a parameter explicitly set by me on the server task should never be overwritten by server itself.
The function "Delete parameter" is misleading here, because the parameter is not deleted by the server. It is still part of the project.
The function "Hide parameters" could be used to remedy this, as already mentioned.
regards,
Adrian
I just wanted to clarify the situation because the team thought we had broken our parameter assignment flow/UI with the last release.
However, it turns out it was actually a feature request in disguise all along
Regarding the 'delete parameter' option (though I believe it's 'add/remove parameters'), it really sounds somewhat misleading. Truly 'removing' a parameter from the project isn't possible, as it would disrupt all actions and calculations involving that parameter. I suppose it could be read as shorthand for 'add/remove parameter value assignments' which makes it clearer what this feature does.
That's interesting. I've never thought about it from that perspective. Perhaps we need to make it more clear that task parameters are an assigned subset of project parameters that take precedence over project parameters.
That’s it. They are hidden, but still in use.
yes, so a button "Hide Parameter" could be a feature request