Jump to content

매뉴얼: 관리자

From mediawiki.org
This page is a translated version of the page Manual:Administrators and the translation is 17% complete.
Outdated translations are marked like this.

Administrators(관리자)는 'sysop'그룹에 속한 위키 유저입니다. 관리자만 사용할 수 있는 미디어위키 기능은 몇 개 없지만, 이 기능들은 매우 중요합니다.

관리 도구

문서 보호

관리자는 보호된 문서를 편집할 수 있고, 문서를 편집할 수 없게 보호하거나 보호를 풀 수 있습니다.

편집 보호 방법은 아래와 같습니다:

  • Semi-protection(준보호): 등록되지 않은 사용자가 페이지를 수정하는 것을 막음.
  • Full Protection(완전 보호): 관리자가 아닌 사용자가 페이지를 수정하는 것을 막음.
  • Cascading protection:
    • 완전 보호와 함께: 관리자가 아닌 사람이 편집하지 못하도록 문서를 보호하고, 동일한 사이트(공용이 아님)에 있는 경우 페이지에 포함된 이미지를 보호하고, 문서에서 끼워넣은 상태로 유지되는 한 끼워넣은 문서에 동일한 보호를 적용합니다(따라서 재귀적으로 작동함). 공용의 파일이나 메타의 사용자 문서는 다른 위키의 계단식 보호로 보호될 수 없으며, 보호하려면 파일 또는 사용자 문서의 임시 사본을 계단식 보호 문서가 있는 위키에 업로드 또는 생성하거나 공용이나 메타에서 완전히 보호해야 합니다.
    • 준보호와 결합된 계단식 보호는 의미가 없으며 피해야 합니다($phab 참조). 끼워넣어진 페이지가 페이지에서 끼워넣어진 상태로 유지되는 동안(다시 재귀적으로) 완전 보호를 적용합니다.
  • 이동 보호는 관리자가 아닌 사용자가 문서를 이동하지 못하도록 보호하는 것입니다.
절차
  • 페이지를 '보호하려면 더보기 드롭다운 메뉴를 클릭하고 "보호" 옵션을 선택합니다(?action=protect또는 URL 주소 표시줄). 그러면 두 개의 메뉴와 확인란이 있는 확인 화면이 나타납니다. 메뉴에서 관리자는 등록되지 않은 사용자 또는 모든 사용자가 페이지를 편집하지 못하도록 보호할 수 있습니다. Similarly, the page can be protected from moves by either unregistered users (although this seems standard anyway) or all users (the system automatically adds the same level of protection to moves as it does to edits, but the protection level can be changed by checking the "다른 보호 설정을 수동으로 설정하기" checkbox). Cascading protection is enabled by checking a separate checkbox. Enter the reason for page protection in the box and press "confirm". This will be logged.
  • To unprotect a page, click the unprotect tab. This will bring up the exact page as above, only this time the two menus will already be selected. Unprotection only involves selecting "(default)" under the "Edits" menu and pressing confirm. A reason for unprotection should be given as well. This action will likewise be logged.
Notes
  • MediaWiki namespace: Pages in MediaWiki namespace can only be edited by users with editinterface user right (by default, administrators and interface administrators). Since MediaWiki 1.32, JavaScript and CSS pages in MediaWiki namespace can only be edited by users with both editinterface and (respectively) editsitecss or editsitejs user right (by default, interface administrators). These restriction is independent of the protection levels of these pages; these pages may still be protected individually.
  • Edit or view source: Depending on the status of the user and the status of the page, a user is provided an edit link or a link to just view the wikitext. After pressing edit on a fully protected page, an administrator is presented a warning at the top of the page informing about this page status. Also, the view source link may sometimes replace an edit link when the user is blocked.
  • Images: Protecting an image is mostly the same as protecting a page (see above). When the protect tab is clicked on the image description page, both the page and the image are protected. The image description page will be protected, and non-sysops will not be able to revert the image to an earlier version, or upload a new version over it.
  • Initially, the main application of cascading protection was protection against creation, by transcluding non-existing pages on a page specially prepared for this purpose, before protection of non-existing pages was enabled in MediaWiki 1.13.Today, it is primarily used to be 100% sure that all components certain pages which change regularly can only be edited by admins, like the English Wikipedia main page, and as a deliberately redundant failsafe in case pages are unprotected accidentally (like w:Wikipedia:Cascade-protected items/content). Additionally, there is a known bug, which causes "view source" to show, even if the user has permission to edit the page with cascading protection.
  • Abuse filters: The AbuseFilter extension can provide additional more complicated filters blocking certain edits.
Configuration
  • which actions can be restricted via the protection interface is determined by the $wgRestrictionTypes setting.
  • which permissions can be required via the protection interface is determined by the $wgRestrictionLevels setting.

문서 삭제

See also: 도움말:삭제 및 되살리기

관리자는 특정한 문서 자체와, 그 문서의 역사를 삭제할 수 있습니다. 또한 삭제된 문서를 보거나 되살릴 수도 있습니다. 위키에 업로드된 사진 역시 삭제할 수 있습니다.

Procedure
  • To delete a page, click the delete link on the page that is to be deleted. (You may also add ?action=delete to the URL address bar). If an administrator is using the Monobook skin, the shortcut Alt+D can alternatively be used. This will bring up a new page asking for a confirmation that the page should be deleted, as well as an explanation of the deletion. A message should be typed into the input box to explain the deletion to other users. After the page has been deleted, it might have an existing talk page which should be deleted as well. Since MediaWiki 1.39, there is a "Delete associated talk page" checkbox that allows you to delete the talk page at the same time as the subject page. Any links that point to the deleted page should be removed or corrected—whichever is the most appropriate action.
  • Pages can be undeleted for as long as they are in the archive. If a page has not been recreated since it was deleted, there will be a message on the page indicating how many deleted revisions there are. Clicking on this (or the undelete tab) will bring up a page displaying all the deleted revisions which can each be looked at separately. To undelete a page, click the restore button which appears on the confirmation page; this will restore all deleted revisions by default. Since MediaWiki 1.39, you can also undelete all revisions of the associated talk page at the same time. Undeletion occurs as soon as the button is clicked, and will be logged just like deletions; if some revisions are not restored, the log will record how many were restored.

    If a page already exists but an administrator wants to restore previous revisions, the administrator must go to the page history. There will be a link to undelete as described above.

Notes
    • Revision deletion
    • It is possible to hide individual revisions from the history, by deleting the article normally, then beginning the undeletion procedure and only checking the chechboxes for the revisions you want to restore—all others will remain deleted. However, it is generally recommended to use [{ll|Manual:RevisionDelete|nsp=0}} for this instead as it is much easier.
    • Delete image revisions: To delete one version of an image, click the (del) link beside that version under the "File history" heading. The most recent version cannot be deleted without deleting all previous versions.
  • Merge edit histories: the edit histories of two articles may be merged into one. To merge histories, delete the page where all the histories are supposed to be restored. Move the other page to the page just deleted, and then restore all the deleted revisions. This can in theory be undone manually, however which revisions originally belonged to which page is lost and would need to be painstakingly reconstructed edit by edit or read from a backup. For simple cases, you should probably use the built-in history merge feature instead, which has no possibility to destroy information.
  • Split an edit history: To split an edit history, manually delete all revisions, then restore those belonging to one article (which may be difficult to recognize). Move the undeleted page to a new title to split off those revisions. Restore the revisions belonging to the deleted page (now a redirect), then revert to the penultimate revision (before the redirect).


Rollback

Any user can revert a page by going back through the page's history. Administrators have a rollback button to expedite the process. To revert the edits of one user to the last version by the previous editor, click rollback on the page history, the user contribution list, or on the diff page. This can be used to revert edits from multiple vandalism attempts. The reversion will be marked as a minor edit and given an automatic edit summary based on the contents of Revertpage.

Sysops (and other users with right "되돌리기를 봇의 편집으로 취급 가능") can hide edits (typically, vandalism) from the Recent Changes page. To do this, add &bot=1 to the end of the url used to access a user's contributions. For example, ...index.php?title=Special:Contributions&target=Username&bot=1. When the rollback links on the contributions list are clicked, both the revert and the original edit that you are reverting will be hidden from the default Recentchanges display. This mechanism uses the marker originally added to keep massive bot edits from flooding recentchanges, hence the "bot". These changes will be hidden from recent changes unless you click the "bots" link to set hidebots=0. The edits are not hidden from contribs, history, watchlist, etc. The edits remain in the database and are not removed, but they no longer flood Recentchanges. The aim of this feature is to reduce the annoyance factor of a flood vandal with relatively little effort.

사용자 차단

See 매뉴얼:사용자 차단 .


Making sysops

미디어위키 버전:
1.11

There is a simple interface (Special:Userrights) for granting a specific username 'sysop' status or (in MediaWiki 1.11) granting and revoking membership to groups with all associated user rights – a user with 'Bureaucrat' status has the rights to do to this. The initial user created by the installer should have 'Bureaucrat' rights.


Signed-in privileges

Users with ordinary access, including visitors who haven't "signed in", can still do many things, including the most important: editing pages and helping with maintenance tasks. But only signed-up users can upload files or rename pages. Among other things, one should also register to hide one's own IP behind the usernames.

See also