@@ -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 |
@@ -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 | } |
@@ -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 |
@@ -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` |
@@ -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. |
@@ -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() |
@@ -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 |
@@ -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'), | |||
|