With perforce, a user can get email notifications of changes to a particular file or directory by specifying it in the Reviews field of the user record (more details in the Perforce documentation).
However, I would like to have email notifications sent to a team mailing list, which is of course not a perforce user. One kludgy way of accomplishing this would be to have a team member put the mailing list in for his email address, while another would be to create a user account for the mailing list (would this require another license?). Surely there has to be better way, though.
If you would like to use a user review field, you are entitled to a free "background user" license that might fit your needs (this way, none of your "real" users would need to change their email address):
A "background user" is a Perforce user
account that is used solely for
automated tasks, such as triggers and
daemons. Perforce customers with
current licenses can have an
additional user added to their license
file, free of charge, on request.
Contact Perforce support for more
information.
Or, you could look into doing what you need with some sort of p4 trigger.
The perforce Review daemon is just a python script available here that runs on the server ( or any machine for that matter ) and polls check-ins on a regular interval and then mails users based on what they have set in the review field of their clientspec.
There's no reason why you can't modify it and extend it to do whatever you want including mailing a team mailing list if you want instead.
I've always rolled my own review daemon ( using the vanilla daemon as a starting point )
Old question, new answers (in 2014).
There are now more than one way to do it:
p4review.py - the original (example) script.
p4review2.py - a rewrite of p4review.py with more features and options.
p4notifyd.pl - a Perl version.
Perforce Swarm - a web-based code review system with email notification support built-in.
Related
In salesforce, we have a scenario, on the trigger of the lead object we are updating some records of Campaign. But the user on the behalf of we are running the trigger does not have edit permissions on the campaign. We are not facing any issue in the update of the campaign because the trigger is running the operation in system mode.
Further, we have applied for the security review and made the changes and added the check of the object isUpdatable() and after it, we are not able to update the campaign due to that check which returns false for isUpdatable().
My questions are, Can we pass the security review without applying that isUpdatable() check? if our process has the business logic to update the campaign/opportunity on the behalf of the user who doesn't have permissions on the campaign/opportunity?
If we can not pass the security review with that check then what could be an alternative for it, where one user who doesn't have permission on campaign/opportunity, performs some operation on lead/contact and we want to update the campaign/opportunity in system mode after that operation?
or is it necessary to provide the permissions of campaign/opportunity to that user?
It's not a coding question as such so it might be closed here. Consider cross-posting to https://salesforce.stackexchange.com/
Generally speaking, your app should be simplifying Salesforce. Adding value by being pre-built, pre-tested use case for this customer and saving clicks for the end user. (let's ignore situations like pulling data from other systems, runinng some crazy Excel file generation that SF can't do easily). With that philosophy - you're supposed to respect the System Administrator's wishes when it comes to security. If admin didn't grant Profile X edit access to field Y - the security review answer is that you should detect it. If you can recover gracefully and continue with your program - cool. If it's critical field - throw an error, force the admin to make conscious decision. Because if you're saving clicks - user would face same problem in normal UI. It's not only "describes", it's also about "without sharing" for example.
There's another layer to it - licensing. In the old days "Marketing User" (to access campaigns) was a separate license, you assigned it by clicking checkbox on User but it had to be purchased. Now it's bit simpler, part of the full user license (I think). But there are still situations where you can't access Opportunities for example (Platform License) or can access only Account, Contact and 10 custom objects (Chatter Plus License or whatever is the new name).
If you abuse system mode to fetch data from objects user is not allowed to see (or save to them) - official answer is that SF loses money because of you. Permission should really be assigned and if needed - license purchased. I'm not a lawyer, I don't know who violates the Master Service Agreement with Salesforce, you or the client that installed the app or both. I'd say read the contracts and see what you can do to protect yourself. If that means your app can't be installed by customers on Essentials/Professional (or it can be installed anywhere but can be used only by full users, not by Platform/Chatter/Community) - well, it is what it is. Decide pros and cons, legal consequences if it gets caught...
They're humans, talk with them. Maybe you'll pass review. Better have a rock solid business case why you need to bypass the check though.
P.S. You know you don't have to do describes anymore? Spring'20 goes live this & next week and "WITH SECURITY ENFORCED" and "stripinaccessiblefields" become generally available :)
P.P.S you really need trigger? Workflow, process builder, flow (yuck) - anything to not have code = not need the isAccessible and if it effectively dies on permissions - it's the client's sysadmin's problem?
We've recently moved off Netsuite as our main CRM, and I've been tasked with disabling it. We still have historic tickets in there that need closing, but I want to disable Netsuite from picking up any new tickets from our support mailbox.
I'm new in this role and have little Netsuite experience. Can anyone tell me how to prevent Netsuite from picking up new support tickets, while allowing us to work on closing the existing tickets? Our new CRM is picking up the new tickets.
I've been googling, but can't find out how to do this. I'm very new to Netsuite, and as soon as I've worked out how to perform the basic admin functions, we're moving away from it. I'm cautious that I need to still allow open tickets to be processed and worked on, so can't just cancel everything down.
Can anyone point me in the correct direction?
Thanks in advance!
There is indeed a forwarder on our support address, forwarding to a unique looking Netsuite address. I've disabled the forward, and also unchecked the Email Case Capture box. This allows us to continue working on already created cases, whilst preventing Netsuite from creating new cases. Problem solved, thanks again Jdg50!
Cases in Netsuite are created either through a form or email capture via forwarding a company address to a Netsuite address.
The Email Case Capture feature at Setup > Company > Enable Features > CRM > Support automatically
converts customer support messages your company receives into organized cases in NetSuite.
Depending on the specific requirements of your business, you can use case capture to create a simple
catch-all support address, or you can create a more sophisticated customer support model by using
Case Profiles.
From: https://docs.oracle.com/cloud/latest/netsuitecs_gs/NSSMG/NSSMG.pdf
Case capture works by forwarding your company’s support email address to a NetSuite-generated
address. You will need to make a note of this when setting up forwarding on your mail server.
Logic dictates that removing/unchecking case capture in this setting will turn off case creation. You may also need to turn off the case forwarding/capture user setup in your exchange, depending on how it was originally setup.
This won't erase existing cases, but it will stop new cases from being created.
My company is trying to satisfy PA-DSS requirements for our application, one of which is quite ambiguous regarding "secure source control", however our auditor has interpreted it as a need for signed revisions. I see "signed commits" in git and Hg but have discovered nothing on the perforce side.
The auditors example as to what he wanted to see is as follows:
"The payment application vendor maintains source code integrity throughout the development process by using a standard hashing algorithm that is created and validated upon code check-in and verified when source code is checked out for modification. The hashing algorithm used is:
• (Example)SHA-256
• (Example)SHA-512
• (Example)MD5"
If you look at http://en.wikipedia.org/wiki/Comparison_of_revision_control_software, in the "Features" table, there is a column for "Signed Revisions" and the perforce section says "Yes"...somebody thought it had support of some kind.
Is this something that could be accomplished using before/after commit triggers? Produce a hash in the before-commit, persist it (somehow) and check it against the one we create in the after-commit? I only learned about perforce triggers 5 minutes ago so I don't even know if they would support the concept (not sure how to persist a value across trigger events, not sure if I have access to file contents on a before-checkout trigger, etc).
Indeed, files which are submitted to Perforce have cryptographic digests which are computed during the submit operation.
These file digests are subsequently checked each time the files are synced to any client workstations, and can also be re-verified directly on the server by using the 'p4 verify' command to determine if the file content has been attacked directly on the server.
You can also observe these digests by running various commands; for example you can run 'p4 fstat -Ol //depot/src/file.c' and look at the 'digest' field.
By the way, what are "PA-DSS requirements"? That's a new acronym to me.
Here's a certain amount of information about the file digests that the Perforce server maintains:
http://www.perforce.com/perforce/doc.current/manuals/cmdref/p4_verify.html
http://kb.perforce.com/AdminTasks/BackupAndRecovery/BadErrorsFromP4Verify
http://www.perforce.com/perforce/doc.current/manuals/cmdref/p4_fstat.html
If the issue involves maintaining a record of the code review process, to establish that the code changes that were reviewed are the ones that were actually submitted, you might develop a workflow that is based on the Perforce "shelve" command.
The most important aspect of the "shelve" command that helps with these sorts of workflows is actually in the "submit" command: "p4 submit -e " directly submits a shelf on their server, without re-transferring the files from the user's workstation.
Therefore, if your process only allows 'submit -e' for submits to certain protected areas of your repository, and only allows submits of shelves that have been reviewed (these would be things you would enforce with your change-submit trigger), then you have confidence that the code that was reviewed is the code that was submitted.
I develop web applications, which use a number of third party applications/code/services.
As part of the job, we regularly check with the Full Disclosure mailing list http://seclists.org/fulldisclosure/ for any of the products we use.
This is a slow process to do manually and subscribing to the list would cost even more time, as most reports do not concern us.
Since I can't be the only one trying to keep up with any possible problems in the code I use, others have surely encountered (and hopefully solved) this problem before.
What is the best way to monitor the Full Disclosure mailing list for specific products only?
Two generic ways to do the same thing... I'm not aware of any specific open solutions to do this, but it'd be rather trivial to do.
You could write a daily or weekly cron/jenkins job to scrape the previous time period's email from the archive looking for your keyworkds/combinations. Sending a batch digest with what it finds, if anything.
But personally, I'd Setup a specific email account to subscribe to the various security lists you're interested in. Add a simple automated script to parse the new emails for various keywords or combinations of keywords, when it finds a match forward that email on to you/your team. Just be sure to keep the keywords list updated with new products you're using.
You could even do this with a gmail account and custom rules, which is what I currently do, but I have setup an internal inbox in the past with a simple python script to forward emails that were of interest.
I have a departmental maintenance that needs to be done roughly every 3 months. The maintenance itself can't be automated (it involves physically swapping a primary and spare piece of networking hardware to verify the spare is still working correctly).
I could put this as a recurring event in Outlook and give it a two week reminder window, but I don't want it to be tied to an individual's account (if I or one of my coworkers leaves the company, I still want the reminder to go to the department).
We're working on implementing Sharepoint and my group has a maintenance calendar, which seems like a lovely place to put this. However, there don't seem to be dated notifications for the events. You can set up notifications if the event changes, and you can subscribe to the calendar and set up a notification via Outlook, but that notification is still a per-user notification.
At this point I'm probably just going to write a cronjob on a linux server that emails a reminder, but I thought I'd ask if there's a way to do it using all these expensive collab tools we're putting in place.
So, any idea how to get notifications of a dated event that is not tied to individual users? I also welcome being told that my entire take on the problem is false as long as it involves some good alternatives. Thanks!
Expanding on Andy's answer (http://www.andrewconnell.com/blog/articles/CreatingCustomSharePointTimerJobs.aspx) if you just put code to send an email in the Execute method of the timer job this doesn't give you anything more than cron.
What you could do is to write code to iterate through the Calendar (actually an Event List) finding any events due soon and sending email to whomever is in the Assigned To field. This could then be called from the Timer Jobs Execute method or using a normal scheduled task. This will be easier to administer changes than cron and could be used for other types of tasks.
A link to get you started - Iterate through Items in a List
Another option would be to use Workflow to send out emails from the calendar
EDIT - Since SharePoint SP2 this no longer works as is as workflows can no longer start themselves (loop) - explanation and workaround
This CodeProject article shows how to develop a feature to send scheduled reminders
Yet another option would be to use one of the 3rd party tools that do this (disclaimer - I work for the first company)
Pentalogic - SharePoint Reminder
Bamboo - Alert Plus
BoostSolutions - Alert Reminder Boost
Finally - whichever method you choose (custom code/workflow/3rd party) you will likely run into trouble with recurring events as SharePoint doesn't provide a way to get an 'expanded' list of all occurrences.
The best way to do this would be using a Timer Job - see Andrew Connell's blog here: http://www.andrewconnell.com/blog/articles/CreatingCustomSharePointTimerJobs.aspx