Cara Navigasi Melalui Pengaturan Aplikasi Redmine (Bagian 2)

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).