In ClearCase GUI, when I tried to check-in, an empty comment field will be shown, which I can fill in check-in messages.
Is it possible to set template for this message?
For example, when the team need to checkin, below message will be shown, and each team member can just fill in the commit message.
Reviewer:
Test suggestion:
Thanks
There is no native template mechanism that I know of.
You can try and see if the ClearCase environment variables could help, like setting in a pre-op checkin trigger a:
CLEARCASE_CMNT_PN
The path name of the file in which cleartool and multitool cache the most recent user-supplied comment. Defining or removing this EV enables or disables comment caching.
(and make sure that file contains a message template)
That thread from 2005 though mentions:
The CLEARCASE_* environment variables are effectively read only (changes to them have no effect.)
Some potential options are:
A) reject comments that do not meet your template and make the user fix them and redo the checkin/out
B) put a wrapper around checkout/in operations to meet your template needs
C) use 'ct chevent' to change the comment during a postop trigger
D) use attributes, hlinks, or labels to store the information instead of using the comment field. (You can apply the attributes, hlinks, or labels during the preop)
I'm thinking that C or D might be your better choices.
Related
I want to limit the keywords that are reported in the output.xml / log.html
Something like, I don't want to log keywords like SET VARIABLE or QUERY, etc., but log only specific keywords that create a meaningful test report
checked multiple questions on StackOverflow
How can I prevent the logging of all keywords except Log keyword in robot framework?
How can I tell robot framework not to log a keyword?
This provides a very close answer at the end, but it is not working and getting into the LOGGER is perhaps not my cup of tea
Have tried FlattenKeywords, removekeywords options, but they dont completely help, as I need more dynamic control over the logging
Tried the SET LOG LEVEL keyword also, but that just removes the information within the keyword, does not remove the whole keyword
Expected results should log only the specific keywords that i mention in the script, something like only the checkpoints are reported and not all the steps
If --removekeywords and --flattenkeywords don't work for you, I can think of two possible solutions.
For one, you could write your own script to filter out all the keywords you don't want from output.xml, and then generate the log.html and report.html after you've run the filter.
You could also create your own log file. You can create a listener that can decide at runtime whether a keyword should be logged or not. You can then write the keyword information to your own custom log file.
I have a View Object which need to be refactored and moved to another package.
Will refactoring the VO also make the necessary changes to its VOImpl class and SDO files?
Yes, all the parts of the VO definition are moved. Notice the "+" sign to the left of the VO name. If you click this it expands and shows all the files that make up the VO definition.
When you move an object via refactoring all the files contained in the object are moved and all references to it anywhere in the model are made. This post has some details that might be useful -but note the date as you do not mention your ADF version. Always indicate the version when asking questions here.
Also the docs.
Stuck at a trivial problem in Grails 3.1.5: Show the fields of a domain object, excluding one of them, including a transient property. Yes, this is my first Grails 3 project after many years with previous versions.
The generated show.gsp contains
<f:display bean="rfaPdffile"/>
This will include a field that may contain megabytes of XML. It should never be shown interactively. The display: false constraint is no longer in the docs, and seems to be silenty ignored.
Next I tried explicitly naming the fields:
<f:with bean="rfaPdffile">
<f:display property='fileName'/>
<f:display property='pageCount'/>
...
</f:with>
This version suprisingly displays the values without any markup whatsoever. Changing display to field,
<f:with bean="rfaPdffile">
<f:field property='fileName'/>
<f:field property='pageCount'/>
...
</f:with>
sort of works, but shows editable values. So does f:all.
In addition I tried adding other attributes to f:display: properties (like in f:table), except (like in f:all). I note in passing that those two attributes have different syntax for similar purposes.
In the Field plugin docs my use case is explicitly mentioned as a design goal. I must have missed something obvious.
My aim is to quickly throw together a prototype gui, postponing the details until later. Clues are greatly appreciated
If I understood you correctly, you want to have all bean properties included in the gsp but the one with the "megabytes of XML" should not be displayed to the user?
If that is the case you can do:
f:with bean="beanName"
f:field property="firstPropertyName"
f:field property="secondPropertyName"
And the one you don't wish to display:
g:hiddenField name="propertyName" value="${beanName.propertyName?}"
f:with
So list all the properties as f:field or f:display and put the one you don't wish to display in a g:hiddenField Grails tag
You can also try:
f:field property="propertyName"
widget-hidden="true"
but the Label is not hidden in this case.
Hope it helps
My own answer: "use the force, read the source". The f:display tag has two rather obvious bugs. I will submit a pull request as soon as I can.
Bugs aside, the documentation does not mention that the plugin may pick up the "scaffold" static property from the domain, if it has one. Its value should be a map. Its "exclude" key may define a list of property names (List of String) to be excluded. This probably works already for the "f:all" tag; bug correction is needed for the "f:display" tag.
My subjective impression is that the fields plugin is in a tight spot. It is intertwined with the Grails architecture, making it sensitive to changes in Grails internals. It is also required by the standard scaffolding plugin, making it very visible. Thus it needs constant attention from maintainers, a position not to be envied. Even now conventions for default constraints seem to have changed somewhere between Grails 3.0.9 and 3.1.7.
Performance of the fields plugin is sensitive to the total number of plugins in the app where it is used. It searches all plugins dynamically for templates.
For the wish list I would prefer stricter tag naming. The main tags should be verbs. There are two main actions, show and edit. For each action there are two main variants, single bean or multiple beans.
My answer is that at present (2 March 2017) there is no answer. I have searched the Net high and low. For the index (list) and create and edit views, the fields plugin works well enough. A certain field can be easily excluded from the create and edit views, relatively easily from the list view (by listing those that should show), and in no way I could find from the show view. This is such a common need that one would suspect it will be addressed soon. Also, easily showing derived values in the show view, like 'total' for an invoice. One can do that by adding an ordered list with a list item showing the value below the generated ordered list of values, but that is kind of a hack.
In some ways, the old way was easier. Yes, it generated long views, but they were generated and didn't have to be done by the programmer - just custom touches here and there.
I'm having fun with a change to a content type field (from a node reference to a text field) which results in an error when a recreated feature is merged. The error is
FieldException: Cannot change an existing field's type. in field_update_field() (line 234 of /var/www/htdocs/modulesfieldfield.crud.inc)
At the moment, this is only affecting a merge back into a developer's workspace and the staging environment is a clean build from GIT, so unaffected. But it raises an early flag in terms of defining an update process when it goes to production.
When in production, I assume that it will be a matter of managing an export of each instance of that content type, remove the content type, install the recreated feature, migrate the exported data into the refactored content type and then apply any tests that may be defined for that change.
What is the recommended best practice process, i.e. the standard to follow to get it right at the outset?
Many thanks in advance
Best way is to tag your feature with a version.
First version: your old field and it's data
Second version: your old field definition and the new one.
In this version you can migrate the data contained in the old field within a hook_update_N().
Third version: simply remove old field definition
I hope to have answered your question as you expected
Is it possible in clearcase to checkout a file for modification such that it is impossible to check it back in? I’m going to be hacking some files on a private branch, only some of which I want to ever check in. I want to eliminate the possibility of accidentally checking in unwanted changes. (I know we can write a trigger to check for magic keywords in the checkout comment; I'm look for something built-in to CC.)
"Hacking some files" is spelled in ClearCase lingo: hijacked files in a snapshot view.
All you have to do is to:
lock those files (except for the few developers you know are likely to checkout/checkin the files: cleartool lock -nusers userA,userB,... aFile)
create a snapshot view
change the read/write right (at the OS level, nothing to do with ClearCase here)
modify them directly (without checkout them first, hence the "hijacked" state)
The OP Kevin Little adds in the comment:
Alas, we only use dynamic views
Easy enough:
"Hacking some files" is also spelled in ClearCase lingo: eclipsed files in a dynamic view.
All you have to do is to:
lock those files (except for the few developers you know are likely to checkout/checkin the files: cleartool lock -nusers userA,userB,... aFile)
create a dynamic view
copy the files you need to modify as aFile.tmp
modify the config spec to not select them
copy them back to their original name (they became "eclipsed" as their private version override their official versioned counterpart)
remove the "none" selection rules from the config spec
modify them directly
To not select them, add to the config spec (ct edcs) before the other rules:
element /a/path/to/aFile1 -none
element /a/path/to/aFile2 -none
...
To restore them, all you have to do is move or remove those files.
They will be dynamically be replaced by their original and still versioned element.
I don't know about the administration. From a user standpoint, you could have 2 views. In one view, checkout the files you don't want to check in. In the other view (your view), check them out unreserved. Then, if you try to check them in, you'll get an error because they're checked out to the other view.