When Admin creates a new user account, an email should go to the created user's mail id.
How can I enable this? Can I do it in "alfresco-global.properties", If yes, how?
I don't think that is possible out of the box. You could however implement this functionality with a java behavior. Be sure to not interfere with the emails that is sent out when inviting external users though otherwise those will get double emails.
Update after doing some research:
Well, someone made a decision to not make the notification option configurable in the create user gui. I have followed the calls made from the GUI down to the repository and it ends up calling a java method documented like this:
/**
* Create a Person with an optionally generated user name.
* This version doesn't notify them.
*
*/
Which means you have to do some coding to implement notifications in this scenario.
Related
I use this sample: 16.proactive-messages - as the base for my bot and it works fine, but I'd like to extend it, so that it can send messages in a group chat without anyone interacting with it first (like sending a "Hello I'm up!" message at startup), because currently it can only respond if someone has mentioned the bot after it has initialized.
Perhaps there is a proper way to get the group chat(s) where the bot resides at the bot initialization?
I've answered before some tips on Proactive messaging, please see here for that.
To answer your question though, the bot can definitely start the engagement, either by replying to an existing message in a group chat or starting a completely new thread in the chat. However, it does require to have been installed initially, either by a user or programmatically (e.g. Graph API). That part only needs to be done once, then you can capture the conversation reference and use it again anytime thereafter. That is shown in the sample I link to in my other answer I referenced above.
It's not possible to send proactive message without prior interaction.
Sending a proactive message is different from sending a regular message. There's no active turnContext to use for a reply. You must create the conversation before sending the message.
Ref Doc: https://learn.microsoft.com/en-us/microsoftteams/platform/bots/how-to/conversations/send-proactive-messages?tabs=dotnet
I'm trying to write a discord bot using JDA, and while I can get the presence of the bot fairly easily, I cannot get the presence of a selected user. An example use case for this might be the user typing in a command like !game and then the bot sends a message telling the user what game they're playing. As far as I know, the bot cannot get the user's game activity without getting the user's presence, and I do not see a way to do so. If I missed it in the documentation, please link the method/class.
After a bunch of digging and documentation reading, I have come to a solution. There is no way to get a presence like I was thinking, but since my original intent was to get the game activity, this solution works. First, the bot must have guild presence permissions granted through the developer portal. Then we need to include the line jdaBuilder.enableIntents(GatewayIntent.GUILD_PRESENCES); before we call the build method in our main method. Finally, to get member activities, we need to include jdaBuilder.enableCache(CacheFlag.ACTIVITY);. This lets us use the member.getActivities() method. Generally speaking, getting data associated with specific users requires enabling guild presences.
I'm new to the Android+Braintree world. At the moment I'm using the Drop-In interface.
What I want to do is the following
"If the user is creating/adding a new card, ask him if he wants to save
credit card information".
I need this info because later I will set the storeInVaultOnSuccess option in the transaction's params accordingly.
Now, it seems that there is no way to insert an element in the drop-in GUI to understand if the user wants to save these data or not.
Fine, so I'm going to add an additional step just after the drop-in interface in which I'm only going to ask the user if he wants to save the credit card data or not.
But the problem is that I don't want to ask this question if he choose an already existent credit card, so I need to know if he created a new card or if he selected an existent one.
Is there a way to perform this task (or is there a better alternative)?
WHAT I'VE ALREADY TRIED:
I've tried to see all the information given in the onActivityResult method, more specifically the content of the Intent given as the 3rd parameter.
What I have is, of course, the EXTRA_PAYMENT_METHOD_NONCE, and then the EXTRA_PAYMENT_METHOD (type com.braintreepayments.api.models.Card), but looking at the code of Card.java I'm not able to understand how to retrieve (if possible) this kind of information.
Thanks in advance.
Full disclosure: I work at Braintree. If you have any further questions, feel free to contact support.
The Drop-In UI doesn't support that workflow because at the time of entry the Drop-In automatically vaults the credit card and just provides the nonce (which doesn't contain any information about the card to the client for PCI reasons). In other words, storeInVaultOnSuccess won't apply since it's already there.
As you say, the way to get around this - while still using the Drop-In - would be to keep a reference to the payment method used in the transaction and ask after the transaction goes through. You can get this by examining the response object:
String payment_method_token = "";
TransactionRequest request = new TransactionRequest()
.amount(new BigDecimal("100.00"));
.paymentMethodNonce(nonceFromTheClient);
Result<Transaction> result = gateway.transaction().sale(request);
Transaction transaction = result.getTarget();
if (transaction.getPaymentInstrumentType().equals(PaymentInstrumentType.CREDIT_CARD){
payment_method_token = transaction.getCreditCard.getToken();
}
// ... other payment method types that you support
However, as you say, this is more complicated. You would have to make some selection based on:
a) when the payment method was created (using createdAt), or
a) comparing the arrays of payment methods before and after the checkout experience
This sort of flow really pushes the limits of the Drop-In, and these sorts of constraints often move developers to switch to a custom integration. In that case you would collect their preference - whether they want it stored - as they enter their credit card information.
I am developing an application(Employee exit process from a company) where a employee requesting for exit and his request would be forwarded to his primary supervisor for approval(We have a table in database where we have respective details about candidates like
employee->primary supervisor->HR Manager. So the supervisor will get an email to approve or reject the request. so depending on the reply of that mail we have to forward the request to HR for further approval or to inform the employee through mail that his request is rejected(the condition is all this should be processed automattically)..
Is there any solution that you can suggest ???
As far as I understood the aim is to develop the described system and the question is about its general architecture.
I'll try to give a couple of tips, hopefully they would help.
The primary indicator of the primary supervisor response is its e-mail reply? If its so, I think its not a good approach.
I wouldn't reply on e-mails for managing a "protocol" which is, essentially a part of the business logic of your application.
Using e-mail is totally fine to "notify" the supervisor that the employee wants to quit.
Now, as for me, you should build a server based application what will run in some container (you mention java), so take a look on tomcat, jetty and so forth.
This application will have the following logic:
The employee that wishes to quit, opens the application and gets to the screen "Report my will to quit" (I omit credentials and everything for brevity) with a button "Report".
Now, when the employee hits the report button, the system should find out who is the direct supervisor of that employee, generate an e-mail to him/her and send.
Now, this mail is a notification it should contain the information like this:
- Employee "John Johnson" has reported that he wants to quit. Please check the now the link should come. The link leads to the aforementioned system (with parameters and everything). The Supervisor now gets to the special screen where he/she has an option to agree (a button) or to disagree (another button).
If the supervisor agrees, the system generated an e-mail to HR and to the employee.
General notes:
Pay attention, everything is done within the system, the e-mail is used only as a notification mechanism.
In addition to this fairly basic functionality the system should "memorize" the state of the whole process. The states should be like "employee X has asked to quit", "the supervisor agreed" and so forth.
The system is independent of the e-mails (If e-mails go offline or something your system will still work). Moreover sometimes the supervisor just wants to enter the system and see what happens there without even opening the e-mail. The same holds for HR.
Of course this explanation is fairly basic, but I guess you've got the idea.
Hope this helps
I'm hoping not to re-invent the wheel -- I'm fairly new to Java, but I need a simple but robust algorithm/code/software to perform email verification for users of a web application (e.g. I only need help with step 4 below). That is, I need to verify the user logging in has access to the email address he/she provides during log in.
The steps I have in mind for the Java middle-tier would be:
Java POJO receives user's email and password from client.
The POJO talks to a database server to verify the email/password combo is valid.
If valid, the POJO sends an email to the email address, asking user to reply to email (or click on some provided link, etc.)
The POJO receives notification (how?) that the user has replied to email (or clicked on link, etc.).
The POJO informs the web-application of success (or failure) of authentication, thereby permitting or denying access to the application.
I can write everything except step 4. Essentially I need a way to send an email to a user and then receive some type of response indicating the user received the email.
Anyone know how this can be accomplished? If not, what do you recommend as the next best/simplest solution?
I'm not using a framework as my Java middle tier is very simple. I'd like to keep the solution lean (meaning, don't want to install/implement more than I need; Spring seems overkill). I read up Shiro, but didn't find any evidence it supports email authentication. Any advice is much appreciated to help me avoid writing unnecessary/unproven routines.
The easiest way is to have some code that connects to the mailbox of the destination address, using either POP3 or IMAP, and waits for new, incoming messages.
When you send the email, you can add a Message-ID header. When the user replies to the email, there will be a References that should have the Message-ID that the user is replying too.
When you can use this ID to correlate what they are responding to.
For safety, you may wish to embed the ID within the message itself (since most folks today don't edit replies), so you can look through the body of the message if for some reason the Reference header isn't supplied. There are other techniques that let you give each mail a customer Reply-To address, that's another way this can be done, but that requires some mail server support.
But, anyway, once you have the message structure figured out, you simply listen to the inbox of the address, and look for new messages. As they arrive, your strip the Message IDs, and flag them as appropriate in the DB, or whatever.
As for "waiting" for the message, you must appreciate that it can be a long wait. Rather than having a POJO waiting for it, rather have a simple process that pings the status. You can have a timer that fires every second, and then checks the database to see if it's been updated, etc. Obviously, this is something you want to be able to cancel.
For all of the mail needs, you can use JavaMail -- it does all this, and it pretty straightforward to use.
there are two controllers involved (two POJOs).
the first connection, for steps 1,2+3 talks to one object in the server. as part of (2) a unique code (the UUID mentioned in comments)is generated and saved to the database.
the second connection, when the user clicks on the link, goes to another controller (another POJO, which could be the same class, or could be a different class, depending on your implementation). that reads the UUID from the link, goes to the database, finds the email associated with the UUID, and marks the email as verified.
update i'm struggling to see what you are missing, but when the user clicks on a link in an email the operating system opens a web browser. the web browser makes a connection to the server. the server receives the HTTP GET request with the UUID in the URL and passes the UUID to the POJO.
some more terms: the process of handling the incoming request in the webserver is typically called "routing" and the general pattern used to structure the code that is called is "MVC". exact details will depend on the application framework you are using. for servlet-based java code there's a mapping from URLs to servlets (servlets are java code implementing a certain interface - a framework might provide the servlet which ultimately invokes what you are calling a POJO, or you might write the servlet yourself, in which case that would be your POJO, although in that case it's a misnomer since it implements a specific interface) in the web.xml file.
also, i guess, the web browser on the client uses TCP to make a connection across the network (almost always this is on top of a protocol called IP because you are using the internet). on top of this, the client "speaks" messages in HTTP. all these different layers are described in the "7 layer osi network model".
there's a huge amount of detail on so many levels. hope that gets you started.
see also http://www.quora.com/What-happens-when-you-type-a-URL-into-your-browser