Story point and story point estimate (duplicate?) fields

[Alexander Brockhoff]

Hi all

On my Jira Cloud instance I have two fields, one called Story Points, one called Story points estimate.

The Story points estimate field is reserved in the custom field view so that I cannot delete it, while the Story Points field is not. I took this to assume one was custom created while the other was from Jira.

However, it seems Jira by default is using the Story Points field on the views for my issues and in the reporting for velocity etc. 

Is there something I am doing wrong? What is the proper use of each field? The estimate field doesn't make much sense to me as a field since the Story Points field seems to track changes to itself over time/in a sprint.

[Nic Brough -Adaptavist-]

No, you'll need to write additional functions to enable JIRA to send by non-standard mail protocols.

[SU HWAN JU]

Hello Nic Brough,

Thank for your answer to my question, I have additional questions about SMTP interface.

Is JIRA SMTP I/F making temperary file in JIRA Web-server?

I try to use daemon program, if JIRA SMTP transfer program make temporary file.

Can you give more detail archtecture about JIRA SMTP interface?

Best regards,

Kenneth

[Nic Brough -Adaptavist-]

No, the work is done in memory, as it should be. I'm not sure you need to care about the details of JIRA to SMTP, it's a standard protocol and JIRA uses standard mail libraries to get the mail sent. If you need to do something differently, then the architecture is irrelevant because you need to replace the whole thing, not part of it. In fact, your best option is to forget it. Your companies lack of support for SMTP is, well, to be polite about it, stupid. They should support it as it's a useful standard. The next best option is to forget the idea of doing it in JIRA. Create a simple mail server that JIRA can send standard decent SMTP mail to, then hack that so that it translates into whatever awkward mail protocol you need to use.

[SU HWAN JU]

I know SMTP policy is stupid in my company(Samsug Electronics), but my company had experience several times of secure data's leak.

So Security policy was made that kind of policy, Changeing of security policy is impossible.

If JIRA can support temprary email sending file in server area, I can easily implementation in our site. Currently, My company purchases 10,000+ users Jira, and additional I try to review Confluence/FishEye/Bamboo. If I can't solve this problem, I should have to cancel Atlassian solution review and purchase plan.

Can you escalate this issue to high level manager?

Thank for your help in advance.

[Nic Brough -Adaptavist-]

Dumping emails out to file is simply not supported inside Jira. It has a *standard* secure email transport system and there's absolutely no need to do anything else. * Until you run into a daft "security" policy ;-) ) What I've been trying to point out is that you have two basic options 1. Replace the whole SMTP sub-system in Jira 2a. Accept SMTP 2b. Accept SMTP but have something that bodges it into another non-standard form. Run an SMTP service on the Jira server and ring fence it to only accept mail from the local machine, and then modify the output of that into a suitable format for your supposedly secure mail system.