RhodeCode - issues: Issueshttps://issues.rhodecode.com/https://issues.rhodecode.com/favicon.ico?16960560042023-12-07T08:07:42ZRhodeCode - issues
Redmine RhodeCode CE/EE - Task #5712 (New): add framework to set some UI settings via .ini file for easie...https://issues.rhodecode.com/issues/57122023-12-07T08:07:42ZMarcin Kuzminski [CTO]marcin@rhodecode.com
<p>Currently there's a distinction on what can be controlled via .ini file vs DB.</p>
<p>some of the options seems to not make sense to be controlled via UI (like svn proxy)</p>
<p>Add a framework so you cna still controll this via .ini, but it will save the value in DB and in case this is defined in .,ini file make it read-only on UI.</p>
<p>e.g if svn.proxy is set in ini, push this value into the DB, and make it read-only in DB.</p>
<p>Tis would greatly simplify deployments on k8s or other docker stacks</p>
RhodeCode CE/EE - Task #5705 (New): 5.X - activate update task automatically over rcstackhttps://issues.rhodecode.com/issues/57052023-11-13T08:06:05ZMarcin Kuzminski [CTO]marcin@rhodecode.com
<p>Because rcstack has enabled scheduler by default, we should activate the periodic update check</p>
RhodeCode CE/EE - Task #5697 (New): Improve CI & CD integrationshttps://issues.rhodecode.com/issues/56972023-10-17T16:31:20ZMarcin Kuzminski [CTO]marcin@rhodecode.comRhodeCode CE/EE - Task #5695 (New): Artifacts - Making artifacts a prime functionalityhttps://issues.rhodecode.com/issues/56952023-10-17T16:28:43ZMarcin Kuzminski [CTO]marcin@rhodecode.comRhodeCode CE/EE - Task #5694 (New): GIT LFS 2.0https://issues.rhodecode.com/issues/56942023-10-17T16:27:54ZMarcin Kuzminski [CTO]marcin@rhodecode.comRhodeCode CE/EE - Task #5404 (New): Add an option to detach review rules when deleting an userhttps://issues.rhodecode.com/issues/54042017-11-22T11:23:48ZMarcin Kuzminski [CTO]marcin@rhodecode.com
<p>In cases there are 100s, and user should be removed we need an explicit option to detach an user from review rules.</p>
<ul>
<li>check what happens then to the old review get changed</li>
<li><p>big fat warning about how it can change old ?</p></li>
<li><p>maybe a replace with X user ?</p></li>
</ul>
<p>again reconsider what this means and if we really should have it !</p>
RhodeCode CE/EE - Task #5400 (New): User group - subgroup supporthttps://issues.rhodecode.com/issues/54002017-11-06T22:00:25ZMarcin Kuzminski [CTO]marcin@rhodecode.comRhodeCode CE/EE - Task #5270 (New): Comments updateshttps://issues.rhodecode.com/issues/52702017-04-05T12:39:52ZMarcin Kuzminski [CTO]marcin@rhodecode.com
<p>Think about emails sent out on on comments:</p>
<ul>
<li>maybe they shouldn’t be inside both </li>
<li>add more context (TODO resolution)</li>
<li>Maybe thread that would allow reading those ?</li>
</ul>
RhodeCode CE/EE - Task #5200 (New): investigate search improvementshttps://issues.rhodecode.com/issues/52002017-02-08T00:59:38ZMarcin Kuzminski [CTO]marcin@rhodecode.com
<p>Search in changelog, proper repo filter, re-check syntax.</p>
RhodeCode CE/EE - Task #4669 (New): disable pytest sugar on nix-buildhttps://issues.rhodecode.com/issues/46692016-12-01T12:52:05ZMarcin Kuzminski [CTO]marcin@rhodecode.comRhodeCode CE/EE - Task #4312 (New): Storage location changeshttps://issues.rhodecode.com/issues/43122016-11-28T02:16:25ZMarcin Kuzminski [CTO]marcin@rhodecode.com
<p>Allow custom location per-repository to help fragmentise the source code storage</p>
<ul>
<li>Who will be allowed to change these settings.</li>
<li>What use cases would that support</li>
</ul>
RhodeCode CE/EE - Task #4299 (New): TEMPLATE repo groupshttps://issues.rhodecode.com/issues/42992016-10-26T23:00:16ZMarcin Kuzminski [CTO]marcin@rhodecode.com
<p>Placeholder repo for specs about TEMPLATE repo groups that can be used for creation of pre-defined projects</p>
RhodeCode CE/EE - Task #4290 (New): Allow to transplant the review status to merged commitshttps://issues.rhodecode.com/issues/42902016-10-21T15:00:18ZMarcin Kuzminski [CTO]marcin@rhodecode.com
<p>In case of pull request merge we currently only leave statuses/comments inside the source repo. For tracability reasons it would be really usefull to push the review statuses back into the origin. At first we should simply support case that only the matched hashes gets transfered the review markers.</p>
RhodeCode CE/EE - Task #4289 (New): [ce, ee] clean up pygments lexer functions + handlinghttps://issues.rhodecode.com/issues/42892016-10-21T14:40:28ZDaniel Ddaniel@rhodecode.com
<p>Currently there are a few lexer functions that seem duplicated/incoherent with each other. This seems to be also tied with the rc extensions which can define custom lexers/file extension mappings in example-ext.py:</p>
<pre><code>
# =============================================================================
# END OF UTILITY FUNCTIONS HERE
# =============================================================================
# Additional mappings that are not present in the pygments lexers
# used for building stats
# format is {'ext':['Names']} eg. {'py':['Python']} note: there can be
# more than one name for extension
# NOTE: that this will override any mappings in LANGUAGES_EXTENSIONS_MAP
# build by pygments
EXTRA_MAPPINGS = {}
# additional lexer definitions for custom files it's overrides pygments lexers,
# and uses defined name of lexer to colorize the files. Format is {'ext':
# 'lexer_name'} List of lexers can be printed running:
# >> python -c "import pprint;from pygments import lexers;
# pprint.pprint([(x[0], x[1]) for x in lexers.get_all_lexers()]);"
EXTRA_LEXERS = {}
</code></pre>
<p>Then there are the functions get_custom_lexer and the FileNode attributes <code>filenode.lexer</code> which don't seem to follow the same logic - the filenode lexer for example seems to prefer a lexer matching the filename instead of a defined custom lexer.</p>
<p>We should use a common base for getting a lexer - one that first returns custom lexer mappings (so that for example .html can be mapped to mako).</p>
<p>Extending on this it could be possible to make the file extension => lexer mapping a per repository setting, exposed via the ui, which would give the best usability in terms of letting each repo specify which lexer to prefer ... again for example <code>.html => mako</code> </p>
RhodeCode CE/EE - Task #4246 (New): [ce, ee, vcs, git] add tests for annotated git tagshttps://issues.rhodecode.com/issues/42462016-09-27T15:46:51ZDaniel Ddaniel@rhodecode.com
<p>Need to add a test that makes sure annotated git tags are correctly dereferenced / peeled to the actual commit they point to.</p>