Is it possible to make a milestone invisible in trac 0.11 ?
I have found custom python modules which are a starting point for doing so but none of them worked so far.
Trac 0.11. is quite out-of-date by now. You'll find a large number of plugins no longer support it. What I'm going to suggest will most likely work in Trac 0.11, but if you encounter bugs then you may have to upgrade to get them resolved.
Where would you like to hide the milestone? If you'd like to hide it from the milestone menu on the ticket form, that is easy - once the milestone is closed it will be hidden from all users that don't have TICKET_ADMIN or TRAC_ADMIN permission.
If you would like the milestone to be hidden from the roadmap, all links to the milestone rendered as disabled, and the milestone not view-able when navigating to the URL /milestone/<milestone name>, you can use the fine-grained permissions module. You can hide the milestone by elevating the permissions that are required to view the module. For example,
[milestone:milestone1]
* = MILESTONE_ADMIN
would hide the milestone from users that don't have MILESTONE_ADMIN.
In Trac 0.11, the module fine-grained permissions module is /sample-plugins/permissions/authz_policy.py (it was moved to /tracopt in later releases). FineGrainedPageAuthzEditorPlugin provides a web interface for editing the authz file.
Related
I am currently using Translate&Adapt as a translation application. My goal is to be able to retrieve translations associated with an existing theme, synced with Github, for a second theme that is also synced to a Github repository. In fact, when I wanted to change my published theme and change the language of my website via a language switcher, the pages were not translated at all due to "broken translations" since the "correct translations" were not synced with the new theme. I would like to know how to perform this synchronization.
I noticed that when I localized the different untranslated texts in Translate&Adapt, there are ids associated with each translation, so I suppose that these ids are linked to the first theme and that it is necessary to either modify them or make the second theme point to these ids (I don't know if this is really possible).
I cloned the published theme's Github repository to a second repository
I connected the second repository to the store (it was therefore in an unpublished state)
I made modifications to the language switcher in the unpublished theme
I published the theme connected to the second Github repository
I noticed that the contents of different sections were not translated.
It should be noted that this repository change is something that cannot be avoided (otherwise, we would have made the changes directly to the published theme)."
Anyway, I am open to any proposals for solutions, thank you in advance!
I also asked my question here: https://community.shopify.com/c/shopify-translate-adapt/new-github-repository-translation-issue/m-p/1920126#M396
This is unfamiliar to me - I am not used to distributing software in this way, but it seems like everything should be working, unless I have made a mistake.
On Bintray, I'm trying to release a thing I forked as I want to include it as a dependency in my lib and my app, instead of directly. It's also a learning thing, so feel free to educate me if appropriate.
I've uploaded everything correctly I believe, and unlike every other question I've seen - I actually have signed up for an OSS account, but still can't see the "Link to JCentre" button -
Did I do something wrong? Or has something changed?
I also am assuming I may have to wait for a while before I can link it.I can see my version badge and so on, but I want to access this via gradle. The section appears on my package information screen, but it says 0 links and there's no buttons.
Thanks guys!
Here is a link to my (EDIT: [now successfully updated]) repository. It is a fork of Galgo to add support for Android M+
In order to be enable to "Link to JCenter", your repository needs to be public and Maven type, you also can't be a trial user (see answer here).
The problem that you are facing is that your repository if Generic and not Maven.
You can check your repository type by navigating to your repository edit page, you'll find the Type field (which can't be edited). It should say Maven.
You can also check the Owned Repositories from the organization profile page. The text in parenthesis states the repository type.
I want to make changes to multiple tickets in Trac - specifically, change the value of several listboxes. A web search found multiple Trac tickets on the subject, with the master being (http://trac.edgewall.org/ticket/525). Reading this ticket suggests to me that this feature has been implemented, but I can't find out how to actually do it. Our Trac "administrator" doesn;t know either. We are running Trac 1.01.
Any help would be appreciated.
Information can be found on the TracBatchModify page. Navigate to the Custom Query page (/query) and you'll see a Batch Modify section at the bottom of the page provided you have TICKET_BATCH_MODIFY permission.
In our group we had plain text passwords on our TRAC wiki pages. Now we are granting external users access to those wiki pages. Of course we removed the passwords from the page.
BUT: In the page history you can still see the passwords.
My question is: Is there a way to restrict the user rights to only see the current version of the page and not the page's history?
Not with Trac core alone.
To be exact, likely you cannot see the passwords in the history (commented version lineup), but in the wiki page view of previous versions. This is where the issue starts to get complicated. Technically it is the same page view template, just with older content retrieved from the stack of wiki content by page name and version.
What you want is to just allow latest version views, but lock older ones. You write a mini-plugin to filter all version requests and redirect for user sessions without appropriate permission, say you define an extra permission WIKI_VIEW_REV and allow to inherit it by WIKI_ADMIN (and of course implicitly TRAC_ADMIN too).
I am looking for a way to add a post-commit or pre-commit hook to my VCS that will allow me to both create and close a trac ticket in one go.
The use-case is for when a bug has been found, and corrected, but a single developer who wants to make sure the project manager can see the fix has been done, when it was done and what milestone the fix has been done in.
We have a default milestone in trac when creating a ticket, so reflecting that information would be good too.
I recommend extending TracTicketChangesetsPlugin to do this.
You would adjust the way it detects the command in the commit message (see http://trac-hacks.org/browser/tracticketchangesetsplugin/trunk/ticketchangesets/commit_updater.py?rev=8114#L154), as you would not have a ticket number to refer to yet.
See http://trac-hacks.org/browser/tracticketchangesetsplugin/trunk/ticketchangesets/commit_updater.py?rev=8114#L215 for where it actually does the parsing. You would have to return some new token to represent "new ticket."
The code that actually changes the tickets is at http://trac-hacks.org/browser/tracticketchangesetsplugin/trunk/ticketchangesets/commit_updater.py?rev=8114#L234 , so here would you create NEW ticket, then close it straight away. To create a new ticket, call Ticket(self.env) and then save it with Ticket.insert() (see http://trac.edgewall.org/browser/trunk/trac/ticket/model.py?rev=9692#L174 ).
If you do this, I recommend attaching your patch to a new ticket at Trac Hacks.
Create a post-commit hook. Notice how the trac post-commit hooks work and copy this functionality to control this action (creation + closing ticket). The creation + closing are two separate http requests that can happen with wget, you can intercept the ticket creation form's post, look at how the existing trac integration works, or hack it some other way. Have fun. I wish this could be more specific but it really does depend on what you're trying to do.