Agree with Remco. It should be a formal property per column.Include in insert handler (default = true) Include in update handler (default = true)
Good idea. Especially useful in multi-language application, you end up with different sort-order per language when using the translation:English:Average Bad GoodDutch:Gemiddeld Goed SlechtGerman:Durchschnitt Gut SchlechtFrench:Bon Mauvais Moyenne
I agree with @Harold and @Arie V that this should be a formal setting. I note down I learned this four years ago but had forgotten it in the meantime. A checkbox / formal setting would have lead to a situation you cannot forget and a more transparent way of solving this problem.
Just create some new ones if they don't exist. Or use default ones like tsf_request_body and tsf_request_method.In my view we should automate these things more. Sometimes just choose something that'll work for the user. I think not a lot of people would be fussed if you created some default domains for these fields.
@Mark Jongeling any update on this idea?
Are you running the latest version of the Universal GUI? If so, it seems to be a bug. Otherwise, try the latest version first.
@Mark Jongeling I think this should be a setting so a developer can choose to enable/disable these buttons. For most users, I think it would be beneficial to have a clear way of removing their previously set up filter. Hiding something in an overflow menu is a last-resort from a usability perspective.
The function is that if you merge before all validations have been solved (you shouldn’t, but hey, sometimes it happens :) ), you can still see to whom these validations belong.
Hey @Dave Bieleveld Starcode, I strongly disagree. Especially when one developer is working on a model you should have code review done. We’ve all had it happen that you go on a specific thought-train, down into a rabbit hole to go for a specific solution, only for a colleague to point you at some flaws you built along the way.I think code review is one of the ways to massively improve the quality of work as well as providing learning opportunities for both reviewer and the developer that has worked on this model.If you, for some reason are the only one able to work on the model and have no colleagues available, I think it would be wise to reach out and ‘outsource’ the code review portion of the work.
Hey @Dave Bieleveld Starcode, I agree with your first statement. Will create an idea to remove that setting in the configuration.Your second statement I do not agree with. I think quality is the one item you cannot scrimp on. You are already a lot faster using the software factory and when looking at total cost of ownership, lack of quality is really expensive.
I’ve made a new idea :)
To add here, the moment of assigning them to the developer is also up for debate. My suggestion would be: after executing validations, that any messages that come out are automatically assigned to the one executing the validation. However, developers could opt to not validate at all and merge any changes to another branch, causing validation messages to appear in that branch and being assigned to a developer that does not know where these messages come from. How should the Software Factory deal with this situation in your opinion? I think part of the requirement for merging is having had a validation run. Or even run it as part of creating the merge session…‘create-merge-session’ → start validating → warn if there are any and ask if user wants to continue → do the actual merge-stuff.I mean, it does not make sense to not run your validations before merging. Make it mandatory.
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.