rhodecode-enterprise-ce Commit - r306:08b6bdad

release: Merge default into stable for release preparation

marcink -

r306:08b6bdad stable

parent child

Context file:

r306:08b6bdad

docs/contributing/checklist-tickets.rst created 644 +137 0

			@@ -0,0 +1,137
		1	.. _checklist-tickets:
		2
		3	=================
		4	Ticket Checklists
		5	=================
		6
		7
		8	Ticket Description
		9	==================
		10
		11	In general these things really matter in the description:
		12
		13	- Reasoning / Rationale. Explain "WHY" it makes sense and is important.
		14
		15	- How to reproduce. Easy to follow steps, that’s important.
		16
		17	- Observation: The problem (short)
		18
		19	- Expectation: How it should be (short)
		20
		21	- Specs: It is fine to draft them as good as it works.
		22
		23	If anything is unclear, please ask for a review or help on this via the
		24	Community Portal or Slack channel.
		25
		26
		27	Checklists for Tickets
		28	======================
		29
		30	BUG
		31	---
		32
		33	Definition: An existing function that does not work as expected for the user.
		34
		35	- Problem description
		36	- Steps needed to recreate (gherkin)
		37	- Link to the screen in question and/or description of how to find it via
		38	navigation
		39	- Explanation of what the expected outcome is
		40	- Any hints into the source of the problem
		41	- Information about platform/browser/db/etc. where applicable
		42	- Examples of other similar cases which have different behaviour
		43
		44	DESIGN
		45	------
		46
		47	Definition: Styling and user interface issues, including cosmetic improvements
		48	or appearance and behaviour of frontend functionality.
		49
		50	- Screenshot/animation of existing page/behaviour
		51	- Sketches or wireframes if available
		52	- Link to the screen in question and/or description of how to find it via
		53	navigation
		54	- Problem description
		55	- Explanation of what the expected outcome is
		56	- Since this may be examined by a designer; it should be written in a way that a
		57	non-developer can understand
		58
		59	EPIC
		60	----
		61
		62	Definition: A collection of tickets which together complete a larger overall
		63	project.
		64
		65	- Benefit explanation
		66	- Clear objective - when is this complete?
		67	- Explanations of exceptions/corner cases
		68	- Documentation subtask
		69	- Comprehensive wireframes and/or design subtasks
		70	- Links to subtasks
		71
		72	FEATURE
		73	-------
		74
		75	Definition: A new function in the software which previously did not exist.
		76
		77	- Benefit explanation
		78	- Clear objective
		79	- Explanations of exceptions/corner cases
		80	- Documentation subtask
		81	- Comprehensive wireframes and/or design subtasks
		82
		83	SUPPORT
		84	-------
		85
		86	Definition: An issue related to a customer report.
		87
		88	- Link to support ticket, if available
		89	- Problem description
		90	- Steps needed to recreate (gherkin)
		91	- Link to the screen in question and/or description of how to find it via
		92	navigation
		93	- Explanation of what the expected outcome is
		94	- Any hints into the source of the problem
		95	- Information about platform/browser/db/etc. where applicable
		96	- Examples of other similar cases which have different behaviour
		97
		98	TASK
		99	----
		100
		101	Definition: An improvement or step towards implementing a feature or fixing
		102	a bug. Includes refactoring and other tech debt.
		103
		104	- Clear objective
		105	- Benefit explanation
		106	- Links to parent/related tickets
		107
		108
		109	All details below.
		110
		111
		112	External links:
		113
		114	- Avoid linking to external images; they disappear over time. Please attach any
		115	relevant images to the ticket itself.
		116
		117	- External links in general: They also disappear over time, consider copying the
		118	relevant bit of information into a comment or write a paragraph to sum up the
		119	general idea.
		120
		121
		122	Hints
		123	=====
		124
		125	Change Description
		126	------------------
		127
		128	It can be tricky to figure out how to change the description of a ticket. There
		129	is a very small pencil which has to be clicked once you see the edit form of a
		130	ticket.
		131
		132
		133	.. figure:: images/redmine-description.png
		134	:alt: Example of pencil to change the ticket description
		135
		136	Shows an example of the pencil which lets you change the description.
		137

docs/contributing/frontend.rst created 644 +153 0

			@@ -0,0 +1,153
		1
		2	==================================================
		3	Code style and structure guide for frontend work
		4	==================================================
		5
		6	About: Outline of frontend development practices.
		7
		8
		9
		10
		11	Templates
		12	=========
		13
		14	- Indent with 4 spaces in general.
		15	- Embedded Python code follows the same conventions as in the backend.
		16
		17	A common problem is missed spaces around operators.
		18
		19
		20
		21
		22	Grunt
		23	=====
		24
		25	We use Grunt to compile our JavaScript and LESS files. This is done automatically
		26	when you start an instance. If you are changing these files, however, it is
		27	recommended to amend `--reload` to the `runserver` command, or use `grunt watch`
		28	- the Gruntfile is located in the base directory. For more info on Grunt, see
		29	http://gruntjs.com/
		30
		31
		32
		33
		34	LESS CSS
		35	========
		36
		37
		38	Style
		39	-----
		40
		41	- Use 4 spaces instead of tabs.
		42	- Avoid ``!important``; it is very often an indicator for a problem.
		43
		44
		45
		46
		47	Structure
		48	---------
		49
		50	It is important that we maintain consistency in the LESS files so that things
		51	scale properly. CSS is organized using LESS and then compiled into a CSS file
		52	to be used in production. Find the class you need to change and change it
		53	there. Do not add overriding styles at the end of the file. The LESS file will
		54	be minified; use plenty of spacing and comments for readability.
		55
		56	These will be kept in auxillary LESS files to be imported (in this order) at the top:
		57
		58	- `fonts.less` (font-face declarations)
		59	- `mixins` (place all LESS mixins here)
		60	- `helpers` (basic classes for hiding mobile elements, centering, etc)
		61	- `variables` (theme-specific colors, spacing, and fonts which might change later)
		62
		63
		64	Sections of the primary LESS file are as follows. Add comments describing
		65	layout and modules.
		66
		67	.. code-block:: css
		68
		69	//--- BASE ------------------//
		70	Very basic, sitewide styles.
		71
		72	//--- LAYOUT ------------------//
		73	Essential layout, ex. containers and wrappers.
		74	Do not put type styles in here.
		75
		76	//--- MODULES ------------------//
		77	Reusable sections, such as sidebars and menus.
		78
		79	//--- THEME ------------------//
		80	Theme styles, typography, etc.
		81
		82
		83
		84	Formatting rules
		85	~~~~~~~~~~~~~~~~
		86
		87	- Each rule should be indented on a separate line (this is helpful for diff
		88	checking).
		89
		90	- Use a space after each colon and a semicolon after each last rule.
		91
		92	- Put a blank line between each class.
		93
		94	- Nested classes should be listed after the parent class' rules, separated with a
		95	blank line, and indented.
		96
		97	- Using the below as a guide, place each rule in order of its effect on content,
		98	layout, sizing, and last listing minor style changes such as font color and
		99	backgrounds. Not every possible rule is listed here; when adding new ones,
		100	judge where it should go in the list based on that hierarchy.
		101
		102	.. code-block:: scss
		103
		104	.class {
		105	content
		106	list-style-type
		107	position
		108	float
		109	top
		110	right
		111	bottom
		112	left
		113	height
		114	max-height
		115	min-height
		116	width
		117	max-width
		118	min-width
		119	margin
		120	padding
		121	indent
		122	vertical-align
		123	text-align
		124	border
		125	border-radius
		126	font-size
		127	line-height
		128	font
		129	font-style
		130	font-variant
		131	font-weight
		132	color
		133	text-shadow
		134	background
		135	background-color
		136	box-shadow
		137	background-url
		138	background-position
		139	background-repeat
		140	background-cover
		141	transitions
		142	cursor
		143	pointer-events
		144
		145	.nested-class {
		146	position
		147	background-color
		148
		149	&:hover {
		150	color
		151	}
		152	}
		153	}

docs/contributing/overview.rst created 644 +111 0

			@@ -0,0 +1,111
		1
		2	=======================
		3	Contributing Overview
		4	=======================
		5
		6
		7	RhodeCode Community Edition is an open source code management platform. We
		8	encourage contributions to our project from the community. This is a basic
		9	overview of the procedures for adding your contribution to RhodeCode.
		10
		11
		12
		13	Check the Issue Tracker
		14	=======================
		15
		16	Make an account at https://issues.rhodecode.com/account/register and browse the
		17	current tickets for bugs to fix and tasks to do. Have a bug or feature that you
		18	can't find in the tracker? Create a new issue for it. When you select a ticket,
		19	make sure to assign it to yourself and mark it "in progress" to avoid duplicated
		20	work.
		21
		22
		23
		24	Sign Up at code.rhodecode.com
		25	=============================
		26
		27	Make an account at https://code.rhodecode.com/ using an email or your existing
		28	GitHub, Bitbucket, Google, or Twitter account. Fork the repo you'd like to
		29	contribute to; we suggest adding your username to the fork name. Clone your fork
		30	to your computer. We use Mercurial for source control management; see
		31	https://www.mercurial-scm.org/guide to get started quickly.
		32
		33
		34
		35	Set Up A Local Instance
		36	=======================
		37
		38	You will need to set up an instance of RhodeCode CE using VCSServer so that you
		39	can see your work locally as you make changes. We recommend using Linux for this
		40	but it can also be built on OSX.
		41
		42	See :doc:`dev-setup` for instructions.
		43
		44
		45
		46	Code!
		47	=====
		48
		49	You can now make, see, and test your changes locally. We are always improving to
		50	keep our code clean and the cost of maintaining it low. This applies in the same
		51	way for contributions. We run automated checks on our pull requests, and expect
		52	understandable code. We also aim to provide test coverage for as much of our
		53	codebase as possible; any new features should be augmented with tests.
		54
		55	Keep in mind that when we accept your contribution, we also take responsibility
		56	for it; we must understand it to take on that responsibility.
		57
		58	See :doc:`standards` for more detailed information.
		59
		60
		61
		62	Commit And Push Your Changes
		63	============================
		64
		65	We highly recommend making a new bookmark for each feature, bug, or set of
		66	commits you make so that you can point to it when creating your pull request.
		67	Please also reference the ticket number in your commit messages. Don't forget to
		68	push the bookmark!
		69
		70
		71
		72	Submit a Pull Request
		73	=====================
		74
		75	Go to your fork, and choose "Create Pull Request" from the Options menu. Use
		76	your bookmark as the source, and choose someone to review it. Don't worry about
		77	chosing the right person; we'll assign the best contributor for the job. You'll
		78	get feedback and an assigned status.
		79
		80	Be prepared to make updates to your pull request after some feedback.
		81	Collaboration is part of the process and improvements can often be made.
		82
		83
		84
		85	Sign the Contributor License Agreement
		86	======================================
		87
		88	If your contribution is approved, you will need to virtually sign the license
		89	agreement in order for it to be merged into the project's codebase. You can read
		90	it on our website here: https://rhodecode.com/static/pdf/RhodeCode-CLA.pdf
		91
		92	To sign, go to code.rhodecode.com
		93	and clone the CLA repository. Add your name and make a pull request to add it to
		94	the contributor agreement; this serves as your virtual signature. Once your
		95	signature is merged, add a link to the relevant commit to your contribution
		96	pull request.
		97
		98
		99
		100	That's it! We'll take it from there. Thanks for your contribution!
		101	------------------------------------------------------------------
		102
		103	.. note:: If you have any questions or comments, feel free to contact us through
		104	either the community portal(community.rhodecode.com), IRC
		105	(irc.freenode.net), or Slack (rhodecode.com/join).
		106
		107
		108
		109
		110
		111

docs/contributing/standards.rst created 644 +177 0

			@@ -0,0 +1,177
		1
		2	======================
		3	Contribution Standards
		4	======================
		5
		6	Standards help to improve the quality of our product and its development. Herein
		7	we define our standards for processes and development to maintain consistency
		8	and function well as a community. It is a work in progress; modifications to this
		9	document should be discussed and agreed upon by the community.
		10
		11
		12	--------------------------------------------------------------------------------
		13
		14	Code
		15	====
		16
		17	This provides an outline for standards we use in our codebase to keep our code
		18	easy to read and easy to maintain. Much of our code guidelines are based on the
		19	book `Clean Code <http://www.pearsonhighered.com/educator/product/Clean-Code-A-Handbook-of-Agile-Software-Craftsmanship/9780132350884.page>`_
		20	by Robert Martin.
		21
		22	We maintain a Tech Glossary to provide consistency in terms and symbolic names
		23	used for items and concepts within the application. This is found in the CE
		24	project in /docs-internal/glossary.rst
		25
		26
		27	Refactoring
		28	-----------
		29	Make it better than you found it!
		30
		31	Our codebase can always use improvement and often benefits from refactoring.
		32	New code should be refactored as it is being written, and old code should be
		33	treated with the same care as if it was new. Before doing any refactoring,
		34	ensure that there is test coverage on the affected code; this will help
		35	minimize issues.
		36
		37
		38	Python
		39	------
		40	For Python, we use `PEP8 <https://www.python.org/dev/peps/pep-0008/>`_.
		41	We adjust lines of code to under 80 characters and use 4 spaces for indentation.
		42
		43
		44	JavaScript
		45	----------
		46	This currently remains undefined. Suggestions welcome!
		47
		48
		49	HTML
		50	----
		51	Unfortunately, we currently have no strict HTML standards, but there are a few
		52	guidelines we do follow. Templates must work in all modern browsers. HTML should
		53	be clean and easy to read, and additionally should be free of inline CSS or
		54	JavaScript. It is recommended to use data attributes for JS actions where
		55	possible in order to separate it from styling and prevent unintentional changes.
		56
		57
		58	LESS/CSS
		59	--------
		60	We use LESS for our CSS; see :doc:`frontend` for structure and formatting
		61	guidelines.
		62
		63
		64	Linters
		65	-------
		66	Currently, we have a linter for pull requests which checks code against PEP8.
		67	We intend to add more in the future as we clarify standards.
		68
		69
		70	--------------------------------------------------------------------------------
		71
		72	Naming Conventions
		73	==================
		74
		75	These still need to be defined for naming everything from Python variables to
		76	HTML classes to files and folders.
		77
		78
		79	--------------------------------------------------------------------------------
		80
		81	Testing
		82	=======
		83
		84	Testing is a very important aspect of our process, especially as we are our own
		85	quality control team. While it is of course unrealistic to hit every potential
		86	combination, our goal is to cover every line of Python code with a test.
		87
		88	The following is a brief introduction to our test suite. Our tests are primarily
		89	written using `py.test <http://pytest.org/>`_
		90
		91
		92	Acceptance Tests
		93	----------------
		94	Also known as "ac tests", these test from the user and business perspective to
		95	check if the requirements of a feature are met. Scenarios are created at a
		96	feature's inception and help to define its value.
		97
		98	py.test is used for ac tests; they are located in a repo separate from the
		99	other tests which follow. Each feature has a .feature file which contains a
		100	brief description and the scenarios to be tested.
		101
		102
		103	Functional Tests
		104	----------------
		105	These test specific functionality in the application which checks through the
		106	entire stack. Typically these are user actions or permissions which go through
		107	the web browser. They are located in rhodecode/tests.
		108
		109
		110	Unit Tests
		111	----------
		112	These test isolated, individual modules to ensure that they function correctly.
		113	They are located in rhodecode/tests.
		114
		115
		116	Integration Tests
		117	-----------------
		118	These are used for testing performance of larger systems than the unit tests.
		119	They are located in rhodecode/tests.
		120
		121
		122	JavaScript Testing
		123	------------------
		124	Currently, we have not defined how to test our JavaScript code.
		125
		126
		127	--------------------------------------------------------------------------------
		128
		129	Pull Requests
		130	=============
		131
		132	Pull requests should generally contain only one thing: a single feature, one bug
		133	fix, etc.. The commit history should be concise and clean, and the pull request
		134	should contain the ticket number (also a good idea for the commits themselves)
		135	to provide context for the reviewer.
		136
		137	See also: :doc:`checklist-pull-request`
		138
		139
		140	Reviewers
		141	---------
		142	Each pull request must be approved by at least one member of the RhodeCode
		143	team. Assignments may be based on expertise or familiarity with a particular
		144	area of code, or simply availability. Switching up or adding extra community
		145	members for different pull requests helps to share knowledge as well as provide
		146	other perspectives.
		147
		148
		149	Responsibility
		150	--------------
		151	The community is responsible for maintaining features and this must be taken
		152	into consideration. External contributions must be held to the same standards
		153	as internal contributions.
		154
		155
		156	Feature Switch
		157	--------------
		158	Experimental and work-in-progress features can be hidden behind one of two
		159	switches:
		160
		161	* A setting can be added to the Labs page in the Admin section which may allow
		162	customers to access and toggle additional features.
		163	* For work-in-progress or other features where customer access is not desired,
		164	use a custom setting in the .ini file as a trigger.
		165
		166
		167	--------------------------------------------------------------------------------
		168
		169	Tickets
		170	=======
		171
		172	Redmine tickets are a crucial part of our development process. Any code added or
		173	changed in our codebase should have a corresponding ticket to document it. With
		174	this in mind, it is important that tickets be as clear and concise as possible,
		175	including what the expected outcome is.
		176
		177	See also: :doc:`checklist-tickets`

docs/release-notes/release-notes-4.2.0.rst created 644 +70 0

			@@ -0,0 +1,70
		1	\|RCE\| 4.2.0 \|RNS\|
		2	-----------------
		3
		4	Release Date
		5	^^^^^^^^^^^^
		6
		7	- 2016-06-30
		8
		9
		10	General
		11	^^^^^^^
		12
		13	- Autocomplete: add GET flag support to show/hide active users on autocomplete,
		14	also display this information in autocomplete data. ref #3374
		15	- Gravatar: add flag to show current gravatar + user as disabled user (non-active)
		16	- Repos, repo groups, user groups: allow to use disabled users in owner field.
		17	This fixes #3374.
		18	- Repos, repo groups, user groups: visually show what user is an owner of a
		19	resource, and if potentially he is disabled in the system.
		20	- Pull requests: reorder navigation on repo pull requests, fixes #2995
		21	- Dependencies: bump dulwich to 0.13.0
		22
		23	New Features
		24	^^^^^^^^^^^^
		25
		26	- My account: made pull requests aggregate view for users look like not
		27	created in 1995. Now uses a consistent look with repo one.
		28	- emails: expose profile link on registation email that super-admins receive.
		29	Implements #3999.
		30	- Social auth: move the buttons to the top of nav so they are easier to reach.
		31
		32
		33	Security
		34	^^^^^^^^
		35
		36	- Encryption: allow to pass in alternative key for encryption values. Now
		37	users can use `rhodecode.encrypted_values.secret` that is alternative key,
		38	de-coupled from `beaker.session` key.
		39	- Encryption: Implement a slightly improved AesCipher encryption.
		40	This addresses issues from #4036.
		41	- Encryption: encrypted values now by default uses HMAC signatures to detect
		42	if data or secret key is incorrect. The strict checks can be disabled using
		43	`rhodecode.encrypted_values.strict = false` .ini setting
		44
		45
		46	Performance
		47	^^^^^^^^^^^
		48
		49	- Sql: use smarter JOINs when fetching repository information
		50	- Helpers: optimize slight calls for link_to_user to save some intense queries.
		51	- App settings: use computed caches for repository settings, this in some cases
		52	brings almost 4x performance increase for large repos with a lot of issue
		53	tracker patterns.
		54
		55
		56	Fixes
		57	^^^^^
		58
		59	- Fixed events on user pre/post create actions
		60	- Authentication: fixed problem with saving forms with errors on auth plugins
		61	- Svn: Avoid chunked transfer for Subversion that caused checkout issues in some cases.
		62	- Users: fix generate new user password helper.
		63	- Celery: fixed problem with workers running action in sync mode in some cases.
		64	- Setup-db: fix redundant question on writable dir. The question needs to be
		65	asked only when the dir is actually not writable.
		66	- Elasticsearch: fixed issues when searching single repo using elastic search
		67	- Social auth: fix issues with non-active users using social authentication
		68	causing a 500 error.
		69	- Fixed problem with largefiles extensions on per-repo settings using local
		70	.hgrc files present inside the repo directory.

rhodecode/admin/__init__.py created 644 +40 0

			@@ -0,0 +1,40
		1	# -- coding: utf-8 --
		2
		3	# Copyright (C) 2016-2016 RhodeCode GmbH
		4	#
		5	# This program is free software: you can redistribute it and/or modify
		6	# it under the terms of the GNU Affero General Public License, version 3
		7	# (only), as published by the Free Software Foundation.
		8	#
		9	# This program is distributed in the hope that it will be useful,
		10	# but WITHOUT ANY WARRANTY; without even the implied warranty of
		11	# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
		12	# GNU General Public License for more details.
		13	#
		14	# You should have received a copy of the GNU Affero General Public License
		15	# along with this program. If not, see <http://www.gnu.org/licenses/>.
		16	#
		17	# This program is dual-licensed. If you wish to learn more about the
		18	# RhodeCode Enterprise Edition, including its added features, Support services,
		19	# and proprietary license terms, please see https://rhodecode.com/licenses/
		20
		21
		22	from rhodecode.admin.navigation import NavigationRegistry
		23	from rhodecode.config.routing import ADMIN_PREFIX
		24	from rhodecode.lib.utils2 import str2bool
		25
		26
		27	def includeme(config):
		28	settings = config.get_settings()
		29
		30	# Create admin navigation registry and add it to the pyramid registry.
		31	labs_active = str2bool(settings.get('labs_settings_active', False))
		32	navigation_registry = NavigationRegistry(labs_active=labs_active)
		33	config.registry.registerUtility(navigation_registry)
		34
		35	config.add_route(
		36	name='admin_settings_open_source',
		37	pattern=ADMIN_PREFIX + '/settings/open_source')
		38
		39	# Scan module for configuration decorators.
		40	config.scan()

rhodecode/admin/interfaces.py created 644 +29 0

			@@ -0,0 +1,29
		1	# -- coding: utf-8 --
		2
		3	# Copyright (C) 2016-2016 RhodeCode GmbH
		4	#
		5	# This program is free software: you can redistribute it and/or modify
		6	# it under the terms of the GNU Affero General Public License, version 3
		7	# (only), as published by the Free Software Foundation.
		8	#
		9	# This program is distributed in the hope that it will be useful,
		10	# but WITHOUT ANY WARRANTY; without even the implied warranty of
		11	# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
		12	# GNU General Public License for more details.
		13	#
		14	# You should have received a copy of the GNU Affero General Public License
		15	# along with this program. If not, see <http://www.gnu.org/licenses/>.
		16	#
		17	# This program is dual-licensed. If you wish to learn more about the
		18	# RhodeCode Enterprise Edition, including its added features, Support services,
		19	# and proprietary license terms, please see https://rhodecode.com/licenses/
		20
		21	from zope.interface import Interface
		22
		23
		24	class IAdminNavigationRegistry(Interface):
		25	"""
		26	Interface for the admin navigation registry. Currently this is only
		27	used to register and retrieve it via pyramids registry.
		28	"""
		29	pass

rhodecode/admin/navigation.py created 644 +124 0

			@@ -0,0 +1,124
		1	# -- coding: utf-8 --
		2
		3	# Copyright (C) 2016-2016 RhodeCode GmbH
		4	#
		5	# This program is free software: you can redistribute it and/or modify
		6	# it under the terms of the GNU Affero General Public License, version 3
		7	# (only), as published by the Free Software Foundation.
		8	#
		9	# This program is distributed in the hope that it will be useful,
		10	# but WITHOUT ANY WARRANTY; without even the implied warranty of
		11	# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
		12	# GNU General Public License for more details.
		13	#
		14	# You should have received a copy of the GNU Affero General Public License
		15	# along with this program. If not, see <http://www.gnu.org/licenses/>.
		16	#
		17	# This program is dual-licensed. If you wish to learn more about the
		18	# RhodeCode Enterprise Edition, including its added features, Support services,
		19	# and proprietary license terms, please see https://rhodecode.com/licenses/
		20
		21
		22	import logging
		23	import collections
		24
		25	from pylons import url
		26	from zope.interface import implementer
		27
		28	from rhodecode.admin.interfaces import IAdminNavigationRegistry
		29	from rhodecode.lib.utils import get_registry
		30	from rhodecode.translation import _
		31
		32
		33	log = logging.getLogger(__name__)
		34
		35	NavListEntry = collections.namedtuple('NavListEntry', ['key', 'name', 'url'])
		36
		37
		38	class NavEntry(object):
		39	"""
		40	Represents an entry in the admin navigation.
		41
		42	:param key: Unique identifier used to store reference in an OrderedDict.
		43	:param name: Display name, usually a translation string.
		44	:param view_name: Name of the view, used generate the URL.
		45	:param pyramid: Indicator to use pyramid for URL generation. This should
		46	be removed as soon as we are fully migrated to pyramid.
		47	"""
		48
		49	def __init__(self, key, name, view_name, pyramid=False):
		50	self.key = key
		51	self.name = name
		52	self.view_name = view_name
		53	self.pyramid = pyramid
		54
		55	def generate_url(self, request):
		56	if self.pyramid:
		57	if hasattr(request, 'route_path'):
		58	return request.route_path(self.view_name)
		59	else:
		60	# TODO: johbo: Remove this after migrating to pyramid.
		61	# We need the pyramid request here to generate URLs to pyramid
		62	# views from within pylons views.
		63	from pyramid.threadlocal import get_current_request
		64	pyramid_request = get_current_request()
		65	return pyramid_request.route_path(self.view_name)
		66	else:
		67	return url(self.view_name)
		68
		69
		70	@implementer(IAdminNavigationRegistry)
		71	class NavigationRegistry(object):
		72
		73	_base_entries = [
		74	NavEntry('global', _('Global'), 'admin_settings_global'),
		75	NavEntry('vcs', _('VCS'), 'admin_settings_vcs'),
		76	NavEntry('visual', _('Visual'), 'admin_settings_visual'),
		77	NavEntry('mapping', _('Remap and Rescan'), 'admin_settings_mapping'),
		78	NavEntry('issuetracker', _('Issue Tracker'),
		79	'admin_settings_issuetracker'),
		80	NavEntry('email', _('Email'), 'admin_settings_email'),
		81	NavEntry('hooks', _('Hooks'), 'admin_settings_hooks'),
		82	NavEntry('search', _('Full Text Search'), 'admin_settings_search'),
		83	NavEntry('system', _('System Info'), 'admin_settings_system'),
		84	NavEntry('open_source', _('Open Source Licenses'),
		85	'admin_settings_open_source', pyramid=True),
		86	# TODO: marcink: we disable supervisor now until the supervisor stats
		87	# page is fixed in the nix configuration
		88	# NavEntry('supervisor', _('Supervisor'), 'admin_settings_supervisor'),
		89	]
		90
		91	_labs_entry = NavEntry('labs', _('Labs'),
		92	'admin_settings_labs')
		93
		94	def __init__(self, labs_active=False):
		95	self._registered_entries = collections.OrderedDict([
		96	(item.key, item) for item in self.__class__._base_entries
		97	])
		98
		99	if labs_active:
		100	self.add_entry(self._labs_entry)
		101
		102	def add_entry(self, entry):
		103	self._registered_entries[entry.key] = entry
		104
		105	def get_navlist(self, request):
		106	navlist = [NavListEntry(i.key, i.name, i.generate_url(request))
		107	for i in self._registered_entries.values()]
		108	return navlist
		109
		110
		111	def navigation_registry(request):
		112	"""
		113	Helper that returns the admin navigation registry.
		114	"""
		115	pyramid_registry = get_registry(request)
		116	nav_registry = pyramid_registry.queryUtility(IAdminNavigationRegistry)
		117	return nav_registry
		118
		119
		120	def navigation_list(request):
		121	"""
		122	Helper that returns the admin navigation as list of NavListEntry objects.
		123	"""
		124	return navigation_registry(request).get_navlist(request)

rhodecode/admin/views.py created 644 +55 0

			@@ -0,0 +1,55
		1	# -- coding: utf-8 --
		2
		3	# Copyright (C) 2016-2016 RhodeCode GmbH
		4	#
		5	# This program is free software: you can redistribute it and/or modify
		6	# it under the terms of the GNU Affero General Public License, version 3
		7	# (only), as published by the Free Software Foundation.
		8	#
		9	# This program is distributed in the hope that it will be useful,
		10	# but WITHOUT ANY WARRANTY; without even the implied warranty of
		11	# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
		12	# GNU General Public License for more details.
		13	#
		14	# You should have received a copy of the GNU Affero General Public License
		15	# along with this program. If not, see <http://www.gnu.org/licenses/>.
		16	#
		17	# This program is dual-licensed. If you wish to learn more about the
		18	# RhodeCode Enterprise Edition, including its added features, Support services,
		19	# and proprietary license terms, please see https://rhodecode.com/licenses/
		20
		21	import collections
		22	import logging
		23
		24	from pylons import tmpl_context as c
		25	from pyramid.view import view_config
		26
		27	from rhodecode.lib.auth import LoginRequired, HasPermissionAllDecorator
		28	from rhodecode.lib.utils import read_opensource_licenses
		29
		30	from .navigation import navigation_list
		31
		32
		33	log = logging.getLogger(__name__)
		34
		35
		36	class AdminSettingsView(object):
		37
		38	def __init__(self, context, request):
		39	self.request = request
		40	self.context = context
		41	self.session = request.session
		42	self._rhodecode_user = request.user
		43
		44	@LoginRequired()
		45	@HasPermissionAllDecorator('hg.admin')
		46	@view_config(
		47	route_name='admin_settings_open_source', request_method='GET',
		48	renderer='rhodecode:templates/admin/settings/settings.html')
		49	def open_source_licenses(self):
		50	c.active = 'open_source'
		51	c.navlist = navigation_list(self.request)
		52	c.opensource_licenses = collections.OrderedDict(
		53	sorted(read_opensource_licenses().items(), key=lambda t: t[0]))
		54
		55	return {}

rhodecode/authentication/tests/__init__.py created 644 0 0

NO CONTENT: new file 100644

rhodecode/authentication/tests/conftest.py created 644 +92 0

			@@ -0,0 +1,92
		1	# -- coding: utf-8 --
		2
		3	# Copyright (C) 2016-2016 RhodeCode GmbH
		4	#
		5	# This program is free software: you can redistribute it and/or modify
		6	# it under the terms of the GNU Affero General Public License, version 3
		7	# (only), as published by the Free Software Foundation.
		8	#
		9	# This program is distributed in the hope that it will be useful,
		10	# but WITHOUT ANY WARRANTY; without even the implied warranty of
		11	# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
		12	# GNU General Public License for more details.
		13	#
		14	# You should have received a copy of the GNU Affero General Public License
		15	# along with this program. If not, see <http://www.gnu.org/licenses/>.
		16	#
		17	# This program is dual-licensed. If you wish to learn more about the
		18	# RhodeCode Enterprise Edition, including its added features, Support services,
		19	# and proprietary license terms, please see https://rhodecode.com/licenses/
		20
		21
		22	import pytest
		23
		24
		25	class EnabledAuthPlugin():
		26	"""
		27	Context manager that updates the 'auth_plugins' setting in DB to enable
		28	a plugin. Previous setting is restored on exit. The rhodecode auth plugin
		29	is also enabled because it is needed to login the test users.
		30	"""
		31
		32	def __init__(self, plugin):
		33	self.new_value = set([
		34	'egg:rhodecode-enterprise-ce#rhodecode',
		35	plugin.get_id()
		36	])
		37
		38	def __enter__(self):
		39	from rhodecode.model.settings import SettingsModel
		40	self._old_value = SettingsModel().get_auth_plugins()
		41	SettingsModel().create_or_update_setting(
		42	'auth_plugins', ','.join(self.new_value))
		43
		44	def __exit__(self, type, value, traceback):
		45	from rhodecode.model.settings import SettingsModel
		46	SettingsModel().create_or_update_setting(
		47	'auth_plugins', ','.join(self._old_value))
		48
		49
		50	class DisabledAuthPlugin():
		51	"""
		52	Context manager that updates the 'auth_plugins' setting in DB to disable
		53	a plugin. Previous setting is restored on exit.
		54	"""
		55
		56	def __init__(self, plugin):
		57	self.plugin_id = plugin.get_id()
		58
		59	def __enter__(self):
		60	from rhodecode.model.settings import SettingsModel
		61	self._old_value = SettingsModel().get_auth_plugins()
		62	new_value = [id_ for id_ in self._old_value if id_ != self.plugin_id]
		63	SettingsModel().create_or_update_setting(
		64	'auth_plugins', ','.join(new_value))
		65
		66	def __exit__(self, type, value, traceback):
		67	from rhodecode.model.settings import SettingsModel
		68	SettingsModel().create_or_update_setting(
		69	'auth_plugins', ','.join(self._old_value))
		70
		71
		72	@pytest.fixture(params=[
		73	('rhodecode.authentication.plugins.auth_crowd', 'egg:rhodecode-enterprise-ce#crowd'),
		74	('rhodecode.authentication.plugins.auth_headers', 'egg:rhodecode-enterprise-ce#headers'),
		75	('rhodecode.authentication.plugins.auth_jasig_cas', 'egg:rhodecode-enterprise-ce#jasig_cas'),
		76	('rhodecode.authentication.plugins.auth_ldap', 'egg:rhodecode-enterprise-ce#ldap'),
		77	('rhodecode.authentication.plugins.auth_pam', 'egg:rhodecode-enterprise-ce#pam'),
		78	('rhodecode.authentication.plugins.auth_rhodecode', 'egg:rhodecode-enterprise-ce#rhodecode'),
		79	('rhodecode.authentication.plugins.auth_token', 'egg:rhodecode-enterprise-ce#token'),
		80	])
		81	def auth_plugin(request):
		82	"""
		83	Fixture that provides instance for each authentication plugin. These
		84	instances are NOT the instances which are registered to the authentication
		85	registry.
		86	"""
		87	from importlib import import_module
		88
		89	# Create plugin instance.
		90	module, plugin_id = request.param
		91	plugin_module = import_module(module)
		92	return plugin_module.plugin_factory(plugin_id)

rhodecode/authentication/tests/functional/__init__.py created 644 0 0

NO CONTENT: new file 100644

rhodecode/authentication/tests/functional/test_settings.py created 644 +77 0

			@@ -0,0 +1,77
		1	# -- coding: utf-8 --
		2
		3	# Copyright (C) 2016-2016 RhodeCode GmbH
		4	#
		5	# This program is free software: you can redistribute it and/or modify
		6	# it under the terms of the GNU Affero General Public License, version 3
		7	# (only), as published by the Free Software Foundation.
		8	#
		9	# This program is distributed in the hope that it will be useful,
		10	# but WITHOUT ANY WARRANTY; without even the implied warranty of
		11	# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
		12	# GNU General Public License for more details.
		13	#
		14	# You should have received a copy of the GNU Affero General Public License
		15	# along with this program. If not, see <http://www.gnu.org/licenses/>.
		16	#
		17	# This program is dual-licensed. If you wish to learn more about the
		18	# RhodeCode Enterprise Edition, including its added features, Support services,
		19	# and proprietary license terms, please see https://rhodecode.com/licenses/
		20
		21
		22	import pytest
		23
		24	from rhodecode.authentication.tests.conftest import (
		25	EnabledAuthPlugin, DisabledAuthPlugin)
		26	from rhodecode.config.routing import ADMIN_PREFIX
		27
		28
		29	@pytest.mark.usefixtures('autologin_user', 'app')
		30	class TestAuthenticationSettings:
		31
		32	def test_auth_settings_global_view_get(self, app):
		33	url = '{prefix}/auth/'.format(prefix=ADMIN_PREFIX)
		34	response = app.get(url)
		35	assert response.status_code == 200
		36
		37	def test_plugin_settings_view_get(self, app, auth_plugin):
		38	url = '{prefix}/auth/{name}'.format(
		39	prefix=ADMIN_PREFIX,
		40	name=auth_plugin.name)
		41	with EnabledAuthPlugin(auth_plugin):
		42	response = app.get(url)
		43	assert response.status_code == 200
		44
		45	def test_plugin_settings_view_post(self, app, auth_plugin, csrf_token):
		46	url = '{prefix}/auth/{name}'.format(
		47	prefix=ADMIN_PREFIX,
		48	name=auth_plugin.name)
		49	params = {
		50	'enabled': True,
		51	'cache_ttl': 0,
		52	'csrf_token': csrf_token,
		53	}
		54	with EnabledAuthPlugin(auth_plugin):
		55	response = app.post(url, params=params)
		56	assert response.status_code in [200, 302]
		57
		58	def test_plugin_settings_view_get_404(self, app, auth_plugin):
		59	url = '{prefix}/auth/{name}'.format(
		60	prefix=ADMIN_PREFIX,
		61	name=auth_plugin.name)
		62	with DisabledAuthPlugin(auth_plugin):
		63	response = app.get(url, status=404)
		64	assert response.status_code == 404
		65
		66	def test_plugin_settings_view_post_404(self, app, auth_plugin, csrf_token):
		67	url = '{prefix}/auth/{name}'.format(
		68	prefix=ADMIN_PREFIX,
		69	name=auth_plugin.name)
		70	params = {
		71	'enabled': True,
		72	'cache_ttl': 0,
		73	'csrf_token': csrf_token,
		74	}
		75	with DisabledAuthPlugin(auth_plugin):
		76	response = app.post(url, params=params, status=404)
		77	assert response.status_code == 404

rhodecode/authentication/tests/test_auth_plugin_base.py created 644 +28 0

			@@ -0,0 +1,28
		1	# Copyright (C) 2016 RhodeCode GmbH
		2	#
		3	# This program is free software: you can redistribute it and/or modify
		4	# it under the terms of the GNU Affero General Public License, version 3
		5	# (only), as published by the Free Software Foundation.
		6	#
		7	# This program is distributed in the hope that it will be useful,
		8	# but WITHOUT ANY WARRANTY; without even the implied warranty of
		9	# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
		10	# GNU General Public License for more details.
		11	#
		12	# You should have received a copy of the GNU Affero General Public License
		13	# along with this program. If not, see <http://www.gnu.org/licenses/>.
		14	#
		15	# This program is dual-licensed. If you wish to learn more about the