Hello,
is it possible at all to include not only the status and most recent comment in messages sent on ticket creation and ticket changes? I'd like to see much more, say all available retrospective information, that is the entire Change history.
Maybe someone already configured Trac this way. If so, I'd be very grateful for information about that configuration, including the Trac version used with that application.
Cheers,
Thx
Trac has change listener interfaces for binding modules to act on changes, i.e. notify on ticket change. See the Trac wiki documentation for descriptions of the I***ChangeListener extension points available by now.
But you'll notice, that the data provided by these interfaces provide only limited information about the changed resource, such as ID and the changed/old vs. new values. So your request can't be solved at all by configuration alone.
While it might be possible to do more complete notification by coding look-ups for additional data in the Trac db, even this isn't possible under all circumstances. Think i.e. about ticket deletion, where everything already has gone when the change listeners are fired with the pre-defined information.
Related
With ga.js I could track offline activity and send to my custom server or store in localhist by overriding the sendHitTask.
Like this:
https://www.google.se/amp/s/www.simoahava.com/amp/analytics/track-users-who-are-offline-in-google-analytics/
How can I achieve the same with gtag.js so I can customize where and in what data structure to send hits?
I know it's been a while since you've asked this question, but I wanted to share my findings regarding this matter:
Although gtag.js doesn't support sendHitTask (or an equivalent, as far as I know) it does support the transport_url parameter.
With this parameter you can set an alternate Transport URL to send the data to. It's originally designed to work with Server Side Tracking but it can also be used to capture requests to /g/collect/ or /r/collect/ endpoints on your own server.
I know it only partially resolves your issue, because you can't fully decide where to send the data. But at least it allows to alter the server where the data is sent.
Hope it helps!
There is an option to persist messages on send on both RTMClient.sendMessageToPeer() and RTMChannel.sendMessage() methods via the SendMessagesOptions interface (which is the optional second parameter on both methods).
However I cannot find information on how and in what form these messages are persisted, and ultimately on how to retrieve the messages history.
Can someone point me in the right direction please? Thank you.
Apparently the feature is still in beta.
This answer is from their official repo at GitHub.
I confirmed with my colleagues, it's shown there but still in beta phase. if you believe you need this feature maybe you can try contacting sales person.
If I make an edit to a Trac ticket, but someone beat me to it, this message is displayed:
Ideally, I would read this message and figure out what I can overwrite and what I should not. But, depending on this message to keep users from overwriting what was submitted is not something that we should depend on:
This may sound a little harsh, but you'll see, when you do usability tests, that there are quite a few users who simply do not read words that you put on the screen. If you pop up an error box of any sort, they simply will not read it.
Is there a better way to prevent these overwrites in Trac - e.g., if a ticket has been modified while you were modifying it, you must refresh the page, etc?
Yes, if the server would send the page modified outside and if the javascript running in your browser could merge that into your local changes. But noone has implemented it in the current trac.
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.
our application wants to be able to create static, searchable pages based on user profile information, which would be linkable to other public profiles.
I am looking at LinkedIn as an example...it seems like they actually auto-generate the page to be a static file that is indexable and searchable.
Can someone suggest how we would do this? I am thinking there would need to be a cron job that runs and writes a the path and file name.
The user may want to keep the whole page private, in which case I imagine it would need to delete it.
There's alot of sub-requirements but that's the general concept and wanted to start getting ideas and feedback.
Thanks.
You can do without the cron job if you generate the static pages in real time whenever the profile information is created/updated or whenever user changed the setting to keep info public/private. This way you are not constantly looping through all users, and do not depend on another component (your cron job) to be running.
One alternative would be to adopt an explicit RESTful information architecture so that a profile resource ("page") is addressable with a permanent URL. The resulting resource could be a static page. Or not. That would be an implementation detail invisible to the search engine crawler and any web browser accessing the resource.
umnik700's answer is fairly dead-on if you're not considering issues related to authentication or who gets to see what. Consider the difference between the profiles you see when you're logged into Facebook versus those same profiles' publicly facing, searchable counterparts. Even MySpace, with a lot less consideration for search engine privacy, has viewability that is dependent on your relationship to the other person, defaulting, for private profiles, to "This profile has been set to private by the user" or something to that extent.
If you're looking to suddenly scale out a social tool where individuals are eliciting their personal information, I would suggest umnik700's answer (dynamically generate the content, but not the URLs, for public versions of the profile) with the following corollary: you need to be able to support privacy preferences varying from extremely strict to completely open, and default to a version that at least errs on the stricter, more private version of the profile. If you're just now pushing out searchable personal content when there never was any way to find it outside the site before, it's important not to abuse information given under different pretenses.
I know this probably requires maybe more scalability and added functionality than you were hoping this project would take, but to do otherwise could be most likely taken as a violation of your user base's tacit trust. Anyway, the best strategy to do this will probably require you to lean on your database more anyway, so it might be time to rework it a bit--including adding some privacy preferences.