Is there a way to change creation and closing date for a ticket ?
Every week I export a report of all created/closed tickets and I need to change date for some of them.
Creation and closing time of a ticket should not be changed. This is the start and the end of a workflow of a ticket.
If you need to get more information in your reports, rethink the ticket's workflow. Trac provides you a workflow,
http://trac.edgewall.org/wiki/TracWorkflow
but you can customise it easily according to your needs through trac.ini.
In the case however you want to hack it, everything is in the trac database and you can change anything by hand, but don't go there.
You cannot change creation date at all, if you define it as the time the ticket is created.
Closing is the act of marking a ticket as resolved (last), so this could be manipulated at least by opening and closing a ticket again.
Related
I'm a brand new to Accurev and I'm having many troubles with it. One of the developers I'm working with has promoted bad code (things are now broken that weren't before) for 2 months on a stream, and I'm wanting to get a copy of the original code before any changes were made to it.
I currently have a workspace, and whenever the other developer creates code, I pull his changes into this workspace attempting to fix the bugs. These changes are promoted to an existing issue within Accurev.
Is there any way I can perhaps create a second workspace and obtain a copy of the original code (before any changes were made)? My target date is March 14th.
I would suggest you revert or demote the bad code that was promoted into the stream (Depending on what version of AccuRev you are using). This would put the stream back into the state it was before the promotion occurred.
Below are some suggested readings on the related topics.
Best way to "un-promote" files in Accurev?
https://community.microfocus.com/borland/managetrack/accurev/w/wiki/26745/purge-revert-and-demote
https://community.microfocus.com/borland/managetrack/accurev/w/accurev_knowledge_base/25951/how-to-revert-changes-in-a-stream
https://community.microfocus.com/borland/managetrack/accurev/w/accurev_knowledge_base/26079/what-is-the-proper-way-to-revert-by-change-package
As an alternative, you could create a time-based stream below the one with the bad code. Set a time basis that predates the bad promote.
To do this, I right-clicked the stream >> New Snapshot.
I select "Specified" and enter the date (with a relative time).
From the Snapshot, I created a New Workspace which was then populated with previous code.
Hope this helps!
I have one vb.net windows application and I want to deliver it to my client with 1 year validity.
After one year this software will automatically stop working or ask for renewal.
The client PC doesn't have internet access.
Please tell me the secure way for this.
When the program is installed, have it set a registry value with the current date. Then, on every subsequent program start, have it check that registry value against the current time. If more than a year has passed, do whatever you plan on doing to lock up your application.
This post has some excellent info on the specifics of adding, modifying, and accessing registry values in vb.net.
Check the date.
If dateToday > dateProgramSold.AddYears(1) Then
'open form that cant be close saying program is expired
End If
When the program is installed, it should ask for an registration key (they could get it by email, print it off and type it). The key should contain the last day of validity (encrypted). Store the key in the registry (or somewhere else). When the program starts, you check the date inside the key.
If they re-install the end date will stay the same.
When they want to update, just send a new key by email or mail.
The amount of security you put into just could depend on how much you trust the company. Because they could always decompile and crack your software.
I needed to do this for a program I wrote. My final solution included the resolution that you can't be 100% foolproof, so I considered my users and did the best I could with what I had.
Without access to the internet, how does the computer know what date it is? It has to rely on user input for it. So if a user can input it, then a user can change it. There is no foolproof way to get an accurate date from the PC without the the user having access to it. Whether from the OS, the BIOS, etc.
So what I ended up doing was putting an obfuscated key into the registry in an obscure place. HKCU >> Software. I made the key just some letters and numbers {L12A3C0DFF} then I named the key Z0B0 and made the value the obfuscated date. I took the year month and day and ran each one through a different calculation. I ended up with something that looked like DDE011468932.
Each time the program ran it decoded this registry setting to see if a year had passed based on the time in the BIOS. If the date in the BIOS was earlier then this date then they changed it and I would not not allow my program to run.
Also each time the program ran, I checked the date in the BIOS and stored this in the registry in the same way. So I would check to see if they changed the date in the BIOS to an earlier date.
So in order for them to abuse the date restriction of one year, they literally had to change the date in the BIOS every day which I figured was not worth it to them to do, besides, they would have had to figure out where I was getting the date from to begin with, which would take decompiling (and I wasn't selling it to a bunch of programmers). Simply changing the date in the OS wouldn't fool it.
In one of the lotus notes db, too frequent replication/save conflicts are caused reason being a scheduled agent and any user working on the document at the same time.
is there any way to avoid this.
Thanks,
H.P.
Several options in addition to merging conflicts:
Change the schedule The best way to avoid it is to have your scheduled agents running at times when users are not likely to be accessing the system. If the LastContact field on a Client document is updated by an agent every hour as it checks all Contact documents, maybe the agent should run overnight instead.
Run the agent on user action It may also be the case that the agent shouldn't be running on a schedule, but should be running when the user takes some action. For example, run the agent to update the Client document when the user saves the supporting Contact document.
Break the form into smaller bits A third thing to consider is redesigning your form so that not every piece of data is on a main form. For example, if comments on recent contacts with a client are currently held in a field on the Client document, you might change the design to have a separate ClientMeeting form from which the comments on the meeting are displayed in an embedded view or computed text (or designed using Xpages).
Despite the fact that I am a developer, I think rep/saves are far more often the result of design decisions than anything else.
You can use the Conflict Handling option on the form(s) in question and select either Merge Conflicts or Merge/No Conflicts in order to have Notes handle merging of edit conflicts.
From the Help database:
At the "Conflict Handling" section of the Form Info tab, choose one of the following options for the form:
Create Conflicts -- Creates conflicts so that a replication conflict appears as a response document to the main document. The main document is selected based on the time and date of the changes and an internal document sequence number.
Merge Conflicts -- If a replication conflict occurs, saves the edits to each field in a single document. However, if two users edit the same field in the same document, Notes saves one document as a main document and the other document as a response document marked as a replication conflict. The main document is selected based on the criteria listed in the bullet above.
Merge/No Conflicts -- If replication occurs, saves the edits to each field in a single document. If two users edit the same field in the same document, Notes selects the field from the main document, based on time and date, and an internal document sequence number. No conflict document is generated, instead conflicting documents are merged into a single document at the field level.
Do Not Create Conflicts -- No merge occurs. IBM® Lotus® Domino(TM) simply chooses one document over another. The other document is lost.
In later versions of Notes there is the concept of document locking, and used properly that can prevent conflicts (but also add complexity).
Usually most conflicts can be avoided by planning to run the agents late at night when users aren't on the system. If that's not an option, then locking may be the best solution. If the conflicts aren't too many, you might benefit from adding a view filtered to show only conflicts, which would make findind and resolving them easier.
IMHO, the best answer to conflicts between users and agents is to make sure that they are operating on different documents. I.e., there are two documents with a common key. They can be parent and child if it would be convenient to show them that way in a view, but they don't have to be. Just call them DocA and DocB for the purposes of this discussion.
DocA is read and updated by users. When a user is viewing DocA, computed field formulas can pull information from DocB via DbLookup or GetDocField. Users never update DocB.
DocB, on the other hand, is read and updated by agents, but agents only read DocA. They never update them.
If you design your application any other way, then you either have to use locking -- which can create the possibility of not being able to update something when you need to, or accepting the fact that conflicts can happen occasionally and will need to be resolved.
Note that even with this strategy, you can still have conflicts if you have multiple replicas of the database. You can use the 'Conflict Handling' section of the Form properties to help minimize replication conflicts, as per #Per Henrik Lausten's answer, but since you are talking about an existing please also see my comment to his answer for additional info about what you would have to do in order to use this feature.
If this is a mission critical application, consider creating a database with lock-documents. That means, every time a user opens a document, a separate lock-document is created.
Then code the agent to see if lock-documents exist for every document that the agent wants to modify. If it does, skip that document.
Document-close should remove the doc-lock.
The lock-doc should be created on document open, not just read. This way, when a user has the document open in read mode, the agent will not be able to modify as well. This is to prohibit, that the user might change to editmode afterwards and make changes.
If the agent has a long modification time, it should create lock-docs as well.
Is it possible to restrict write access to a Perforce depot, but still allowing particular changelists? Basically, instead of spending lots of time managing users in a write-enabled group during a code lock (add user, wait for check-in, remove user) I'd rather just have a list I add approved changelist numbers to.
You can create a trigger script to do it. I do the same thing using JIRA. When someone types in a comment, they include the Jira number. My trigger queries the Jira, and makes sure there is the appropriate comment in the Jira before allowing them to submit.
You can't really do it on changelists since you don't know the changelist number until the actual submit happens.
Why isn't it standard behavior for Accurev to automatically run an "Update" upon opening the program? "Update" updates a user's local sandbox with the latest files from the building/promoted area.
It seems like expected functionality that the most recent files should be synchronized first.
I'm not claiming that it should always update, but curious as to why an auto-Update wouldn't be correct.
Auto-updating could produce some very unwanted results.
Take this scenario: you're in the middle of a development task, but you've made a mistake and need to revert a file that you just modified. So you open AccuRev, but before you have a chance to "revert to most recent version", you are bombarded with 100 files that have been changed upstream including the one you want to revert. You are now forced into the position of resolving all the merge conflicts before your solution will build, including the merge of your (possibly unstable) code in progress.
Requiring the user to manually update keeps a protective 'bubble' around the developer, allowing them to commit (keep) changes within their own workspace without bringing down code changes that could destabilise the work in their sandbox. When the developer gets to a point where his code is ready to share with others, that is the appropriate time to do an update and subsequently build/retest the merged codebase before promoting.
However there is one scenario that I do believe auto-updating could be useful: after a workspace is reparented. i.e. when a developer's workspace is moved from one part of the stream hierarchy to another. Every time we reparent we have to do a little dance:
Accept the confirmation dialog that reminds us (rather verbosely) that we need to update our workspace before we can promote any changes.
Double-click the workspace to view its files.
Wait for AccuRev to do a "Pending" search, to determine whether any file changes are waiting to be committed.
And finally, perform the Update.
Instead of just giving us a confirmation dialog, it would be nice if AccuRev could just ask us if we want to Update immediately.
I guess it depends on preference. I for one wouldn't like the auto-update feature.
Imagine you have a huge project and you don't want to build it every time you start Accurev. But you also can't debug because the source files and debugging info no longer correspond.