en
Language
  • en
  • de
  • fr
  • es
  • br
  • ru
  • jp
  • kr
AI translation
  • cs
  • hu
  • it
  • pl
  • nl
  • tr
  • ae
  • se
  • ua
  • id
  • vn
  • cn
  • th
  • ro
  • bg
  • dk
  • fi
  • no
  • gr
  • il
  • ee
  • eu

How to Navigate Through Redmine Application Settings (Part 2)

12/1/2020
9 minutes

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.

Try Easy Redmine in 30 days free trial

Access all features, SSL protected, no credit card required.