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.
Related
We have an ERP Program used to create and manage stock / orders. Somehow an order has vanished - this should not be possible. It should be possible to cancel an unwanted order, but never delete it completely.
The order in question was created, printed and sent to a customer - and then disappeared. I know the Primary key and Table info, and want to search the log to see if this was somehow deleted, or perhaps there was a rollback.
How can I translate/search the log in this way?
Please note: I did not write this program, and its not my job to fix it.
I just need to diagnose the issue and contact the SW Vendor, if required, and have them fix it. As such I cannot post any code.
With so little information it is hard to give a definitive answer.
I'd start by searching the regular logs. If you have some kind of audit trail mechanism that would be a great help!
If a search through the regular logs doesn't find you the answer then I would:
Get a copy of the database
Go through the REDO logs using the appropriate DBA tools. Since I'm not an sqlanywhere DBA I would get help from one.
When I found the place in time where the order was deleted I would find any other information I could get. The user that did the commit or users that where logged on at the time (I don't know exactly what kind of information you can get here). Also, go back to the other logs you may have and check around that time stamp.
To learn exactly how to go through the redo logs of an SQL Anywhere database you should first try your google luck and then ask in Database Administrators.
Solved!!!!
The Sybase Central tool has an option (which I couldn't find in the manual and missed the first time I looked), which can translate a log file into a series of statements and create a *.SQL file.
Tools -> SQL Anywhere -> Translate Log File -> Follow wizard (which hopefully for you is in a language that you speak, for me it was not).
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.
I'm in the process of developing an app that manages the inventory in a shop. I assume that there could be potentially more than one user working with the app and therefore a scenario where both could reserver for checkout the same item (but for two different recipients is a likely one.
Are there any gems that or techniques someone could recommend that could help with this?
When the users create a new order they get the list of objects that are not reserved (this is a rental shop) but if one leaves the form open for a bit, without making the reservation, someone else still sees the item as available.
Can anyone offer advice about this? Hope the question is not too vague.
Is callbacks the way to go, by creating a before_save validation?
Thank you!
You can use a gem like delayed_job where you can schedule a job to be run at certain time, in this case, after a certain timeout.
You can then schedule a job which removes the reservation status on an item. If the user is successful in reserving the item, the delayed job needs to be deleted.
To delete the item from this activerecord table, you can find it based on the table attributes specified here.
I need to find out that how many times and which files are fixed or changed due to a bug between two specific dates in an open source project which uses Trac. I selected Webkit project for that purpose. (https://trac.webkit.org/) However, it can be any open source project.
What can I do for that? How do I start? Do i have to use version control systems like svn or git for intergration? I am kinda newbie for these bug-tracking and issue-tracking systems.
I'm not certain I exactly understand your question, but...
If you browse to the directory containing the files you care about in the Trac site, then click on Revision Log, you will get a list of changesets that affected that directory. You can select the revisions that span the timeframe of interest and then View changes and you will get a summary of the changes, and depending on the size of the changes and the particular Trac configuration, you may get the diffs on that page as well.
Now, that won't tell you how many times those files were changed, just the net changes.
It also won't tell you which bugs those changes were for.
If you really need to filter on what bug, you'll have to determine how that information is tracked by the particular project; and some might not track it directly. The project might include a #123 in the commit message. If you can rely on that, you could use svn log --xml {2009-11-01}:{2009-12-01} ... to get an xml version of the commit log which you could then parse and filter based on the presence of the bug's ticket number in the commit message. From that, you should have a list of the revisions that you care about.
I'm a fan of Trac, and of course when I'm just using it for my own, lone, projects I can just give myself full admin rights.
When there are other developers involved, or a not-very-technical manager (or, for that matter someone that is a designer rather than hard-code developer), that needs to be able to keep up with what is happening - and do things like add/update tickets, but not potentially break anything, then the fine-grained nature of the permissions gets to be a little more complicated as to what is required for someone.
What permissions do you use for those groups of people (and other similar ones)?
I generally avoid giving the *_ADMIN perms to users if I can avoid it. Trac 0.11 makes that a little easier by adding TICKET_EDIT_DESCRIPTION.
Depending on the setup and the culture, I'll grant the *_VIEW permissions to authenticated (everyone who has logged in) or in lax setups, anonymous (everyone, even not logged in).
I will generally create a developer group, grant the various permissions to that group. Then you just add people to the group (or add the group as a permission to the user, same thing). Do the same for designer, manager, tester, etc.
A manager would want the various ROADMAP_* and MILESTONE_* permissions. I'd be cautious about REPORT_ADMIN unless the manager actually knows SQL. My boss is generally happy to give me an example spreadsheet of the report he wants and I'll whip up a report for him. Be sure to point out to them that if they setup a custom query that does what they want, they can bookmark it -- everything is in the URL -- so they can go back to exactly that same query with current data using that bookmark.
You'd probably want to let authenticated file and append to tickets--doesn't usually who notices a bug, you still want to know about it. If you lock down the workflow permissions enough, you may be able to give out TICKET_MODIFY to more people as well, though that route will be a bit more work.
Those you have some trust in can probably be granted TICKET_EDIT_DESCRIPTION so they can fix up their bug report formatting when they forgot to to start with.
If you have a lead developer, that individual user should probably have TICKET_ADMIN to deal with adding versions and such.
I typically turn on all the VIEWs, plus WIKI_CREATE, WIKI_MODIFY, TICKET_CREATE (or TICKET_CREATE_SIMPLE if using the Simple Ticket plugin) and TICKET_APPEND.
For users I trust to have a little more power, I'll also turn on TICKET_MODIFY.
For a non-technical manager, I'll also turn on MILESTONE_ADMIN. For a technical manager, I'm likely to jump to TRAC_ADMIN -- but if that's too far, at least add REPORT_ADMIN.
Typically, I'll go ahead and give the developers TRAC_ADMIN... but if you don't trust them that far, the above permissions through the power user level plus TICKET_ADMIN are probably sufficient.