How to Navigate Through Redmine Application Settings (Part 2)
This is the continuation of How to Navigate Through Redmine Application Settings (Part 1). Here's an easy guide for you.
Projects
New projects are open as a matter of course
The default condition of recently made projects. The task can even now be made non-open while making a new project or after the making of the project.
Default empowered modules for new projects
Default trackers for new projects
Create consecutive project identifiers
This setting will let Redmine propose consecutive project identifiers for you. This can at present be physically changed just while making the project, not thereafter.
Job given to a non-administrator user who makes a project
Characterizes which job is given of course to a non-administrator client who makes a project (this possibly applies when you have arranged Redmine authorizations so that non-administrator clients are really advantaged to make projects).
Issue following
Permit cross-project issue relations
Whenever set to Yes, relations between issues from various tasks can be made. Default: No
Permit cross-project subtasks
Characterize a few cutoff points for subtasks. The Definitions that are utilized are similar to variant sharing, reported in RedmineProjectSettings. Default: With project tree
Choices are:
- Disabled: a parent assignment can just have subtasks in a similar project.
- With all projects: a parent errand can have subtasks in some other project.
- With project tree: a parent errand can have subtasks in a similar task, predecessor projects and every one of their relatives (for example likewise "kin projects", "cousin projects", and so on.).
- With project chain of importance: a parent errand can have subtasks in a similar task, subprojects, or precursor projects.
- With subprojects: a parent project can just have subtasks in a similar project or subprojects (not in parent projects or irrelevant projects).
Permit issue task to groups
Utilize current date as start date for new issues.
Show subprojects issues on main projects as a matter of course
Whenever set to valid, subprojects issues will be shown as a matter of course on the issue rundown, schedule and gantt of the primary projects (Since r1198). Default: Yes
Figure the issue done proportion
Characterizes how the Issue Done Percentage is set.
- Utilize the issue field (default): Users can physically set % done.
- Utilize the issue status: Each issue status can be relegated a rate. This empowers the "% Done" choice for issues and the "Update issue done proportions" order in the issue statuses review.
Non-working days
- Issues send out cutoff
- Most extreme number of issues contained in CSV and PDF trades. Default: 500
- Most extreme number of things showed on the Gantt diagram
Default segments showed on the issue list
This setting lets you characterize which segments are shown on the issue records of course.
Just custom fields that are set apart with respect to 'all projects' can be chosen here.
Time tracking
Required fields for time logs
Files
max. size
Most extreme size of transferred records (in kibi-bytes). Default: 5120 (for example 5 mebi-bytes)
Max size of text documents showed inline KB
It gives an approach to constrain the most extreme size of text documents which are show inline.
Max number of diff lines showed
It gives an approach to constrain the greatest number of diff lines which are shown by Redmine.
Archives encodings
This choice lets you indicate favored encodings for storehouse records (numerous qualities permitted, comma isolated). These encodings are utilized to change over documents substance and diff to UTF-8 with the goal that they're appropriately shown in the program.
When entering various encodings, the primary legitimate encoding with respect to the record content is utilized.
For French clients, this choice can be for instance set to:
UTF-8, ISO 8859-15, CP1252
For Japanese clients:
UTF-8, CP932, EUC-JP
Email notifications
Outflow mail address
Email address utilized in the "From" field of messages sent to clients.
Blind carbon copy (bcc)
Whenever set to valid, email warning will be sent as Blind duplicate. Default: Yes
Plain content mail
Whenever set to valid, messages are sent in plain content just (no HTML).
email header
email footer
Here you can enter some content that will be added to the messages sent by the application.
Incoming emails
See for nitty-gritty guidelines about these settings RedmineReceivingEmails.
Shorten messages after one of these lines
These settings can be utilized to expel marks from approaching messages.
Empower WS for approaching emails
Redmine can be arranged to permit issue creation or remarks by means of email. So as to utilize that include, you need to empower the API that gets messages. That is the place this setting is for. Default: Off
API
Inside this setting, you can enter a mystery key utilized for the issue creation or remarks by means of email highlight.
Repositories
Empowered SCM
Here you can (de)select the SCM-frameworks Redmine should "give" to the individual ventures. This setting is helpful in the event that you just help a few SCM-frameworks (for example just Git or just SVN).
Bring commits naturally
In the event that this alternative is initiated, the application consequently recovers the new updates when a client counsels the store.
Default: Yes
You can incapacitate this alternative and computerize the call to Repository#fetch_changesets utilizing cron to normally recover the updates for the entirety of the stores out of sight.
Model:
ruby content/sprinter "Repository.fetch_changesets" - e creation
For Redmine 2.x:
ruby content/rails sprinter "Repository.fetch_changesets" - e creation
For Redmine 3.x:
container/rails sprinter "Repository.fetch_changesets" - e creation
You can likewise call this errand from your archive in a post-submit or post-get snare, so that changesets are brought after each submit.
Empower WS for repository management:
This choice ought to be enacted just in the event that you introduced the content for programmed SVN storehouse creation. Default: No
Store the board WS API key
A mystery key for repository management WS.
Most extreme number of revisions showed on file log
It gives an approach to constrain the measure of amendments which are recovered from the SCM for a specific, perused way.
Apply text formatting to submit messages
Referencing issues in submit messages
When brought from the vaults, submit messages are examined for referenced or fixed issue IDs.
These alternatives let you characterize watchwords that can be utilized in a submit message to reference or fix issues consequently, and the status to apply to fixed issues.
Default watchwords are:
- for referencing issues: refs, references, IssueID
- for fixing issues: fixes, closes
There's no default status characterized for fixed issue. You'll need to indicate it in the event that you need to empower auto conclusion of issues.
In the event that you need to reference issues without utilizing keywords, enter a solitary star: * in the Referencing keywords (Administration/Repository) setting. For this situation, any issue ID found in the message will be connected to the changeset.
Case of a working submit message utilizing default keywords:
This commits refs #1, #2 and fixes #3
This message would reference issues 1 and 2 and consequently fix issue 3.
After a watchword issue IDs can be isolated with a space, a comma or and.
The watchwords are case insensitive and in any event one blank space or colon is required between the catchphrase and the primary hash to create a match. More models that will create a similar outcome as the model above:
Commit refs:#1, #2 and fixes #3
Commit Refs #1, #2 and fixes #3
Commit REFS: #1, #2 and fixes #3
Enable time logging
Permits time logging straightforwardly from submit messages. This possibly bodes well on the off chance that you enacted the "Time following" module in said venture. For this situation, you can include exceptional words in your submit message to demonstrate the time you spent on an issue.
The essential sentence structure for doing that is: @<time>, where time comprises in various hours or minutes.
Here's a rundown of numerous legitimate submit messages that would work on the off chance that you need to state you spent N hours on issue 1234:
Implement feature #1234 @2
Implement feature #1234 @2h
Implement feature #1234 @2hours
Implement feature #1234 @15m
Implement feature #1234 @15min
Implement feature #1234 @3h15
Implement feature #1234 @3h15m
Implement feature #1234 @3:15
Implement feature #1234 @3.25
Implement feature #1234 @3.25h
Implement feature #1234 @3,25
Implement feature #1234 @3,25h
Activity for logged time
This is the kind of action that ought to be utilized when recognizing there's a log time in a submit message (see above).
Looking for a Redmine upgrade? Easy.
Get all powerful tools for perfect project planning, management, and control in one software.