jira 5.1 inline editing... how this will work for you?

[JamieA]

Was wondering if anyone has opinions on the upcoming inline editing in jira 5.1. In a nutshell, you click on the field in the view screen, then edit it and press the tick or tab away. One of the big Atlassiguys told me that 90% of issue edits are single fields, so this makes sense. I guess editing fields in the issue navigator will follow shortly thereafter.

One thing I'm confused about is if you edit two fields on the issue will it send two notifications? Presumably it waits a while then batches them in to one. EDIT, in the EAP at an rate it sends a mail for every field edited inline.

Here's my concern. Organisations with complex processes need to validate multiple different fields in concert with each other. If you edit and commit one at a time, I don't see how that can be done. The new way of editing doesn't seem to allow for saying: if you set the due date you must also fill in the "reason for due date" field, or if you select country Mexico then XYZ option is not valid for field ABC.

And I'm also looking at the amount of work required to make the behaviours plugin compatible, if it's even possible, and wondering whether I will discontinue it.

BTW you can download the milestone release from http://www.atlassian.com/software/jira/download-eap - it's worth a look.

[Nikola ILO · Accepted solution]

UPDATED 04/10/13: Code much cleaner now, but function needs to be called directly in the view template of the customfield to work.

This is how it works for us:

disableInlineEditForCustomField : function(customfieldId) {
        var oldEditable = JIRA.Issues.IssueFieldModel.prototype.isEditable;
        JIRA.Issues.IssueFieldModel.prototype.isEditable = function(){
            return (customfieldId != this.id) && oldEditable.call(this);
        };
    }

We just disable customfields that should not be inline editable. To use this you need to execute the disableInlineEditForCustomField function directly in the view template of the customfield.

It works quite good, still any suggestions on how to improve the code are appreciated :-)

[JamieA]

Hi Nikola. Could you describe what the code above actually does, or what you're trying to achieve?

cheers, jamie

[Nikola ILO]

Our Plugin (https://marketplace.atlassian.com/plugins/at.celix.jira.plugins.zones ) has customfields that depend on each other. It is not possible to change one without the other.

The first work-around for our customers was to completely disable inline editing in JIRA 5.1, to prevent inconsistent data.

We now use disableInlineEditForCustomField to selectively disable inline edit only for our customfields.

You only need to call disableInlineEditForCustomField('customfieldID') on the view issue screen to disable inline editing for a customfield.

[Valentijn Scholten]

Pretty cool approach.

[resah]

Thanks Nikola, safed me hours :)

[Nancy Belser]

Hi Nikola,

Thanks for providing a solution. I have a question about it, though. How do I integrate this code into the View Issue screen?

Thanks!

[Nikola ILO]

Hi Nancy,

there are several ways for doing that, we use a web resource module in our plugin, which is included in the atl.general context.

You could probably put the code also directly in the velocity view template of your custom field.

[Nancy Belser]

Thanks, Nikola. I will try the web resources module plugin.

[JamieA]

Hi Nikola,

I tried your code, it works of course. From the console anyway.

The problem I am having is that the fields are made inline editable by an ajax call, which takes a few hundred ms... it's the EditAction.jspa which returns JSON containing the inline edit html which is swapped in when you click on a field.

When your code is called from document.ready, it runs before the fields are made inline editable, such that AJS.$(this).is('.editable-field') does not match.

Does this not cause you any problems? I took a look at your code in the plugin, and I don't quite understand why it's working, as it disables edits on document ready.

cheers, jamie

[Nikola ILO]

Hi Jamie,

you have to call the function after the field has been loaded. You can do this best directly in your velocity-edit template.

[JamieA]

I still don't see how you can be sure that the fields have been made inline-editable by the time you call the function. It doesn't work for me unless I put a delay on the function...

There should be some way of providing a callback to the JS that makes them inline-editable, but there is not afaik.

[Nikola ILO]

The delay is provided by the user, either by

view.delegate('*,', 'mouseover', disableFunction);

or by

view.hover(disableFunction);

AJS.$(this).is('.editable-field') is called when the user hovers over the field.

While hovering there are 2 possibilites:

1) field is already .editable-field -> it gets disabled

2) field is not .editable-field yet -> user can't inline edit yet

Can you give a better trace on when the race condition occurs?

[JamieA]

Hrm, thanks. I though the hover delegate was only applied to fields with a certain class, and when the code runs they don't have that class. I'll get back to you here with more info on that.

Thanks for the info.

[Murugesan Guruswamy]

Nikola,

Thanks for the wonderful solution to disable inline edit. But I have a situation where the keyboard shortcut is used to enable with ,(comma). How to disable it when it is pressed?

Thanks in advance.

[Valentijn Scholten]

I think a better way to disable inline edits is on page load.

Currently when a user hovers with his mouse close to a field it changes shape to indicate that you can edit it. If you click it quick enough you can edit it, but most of the time it changes shape again and says "inline editting disabled". I am getting questions about this.

[Nikola ILO]

@Murugesh

I didn't consider the keyboard shortcuts. If I find some time I will adept the code such that it block the shortcuts too.

@Valentjin

I did try to do it on page load, but didn't get it working. It is the better way to do it.

[AbrahamA]

Hi Nikola

keyboard shortcut got me stuck as well, look forward for your solution.

Thanks

Abe

[Nikola ILO]

Hi all,

I've upated our code to patch the original JavaScript. This fixes all issues reported by you, including keyboard shortcuts and timing errors.

The new solution works entirely different to the old one. It must be executed after the atlassian batch.js and before initIssueObjects(). You can best achieve this through calling the function directly in the view template of the customfield.

Currently we've only tested it using JIRA 6 but it should work with the previous versions too.

[Deleted user]

I am upgrading to JIRA 6.3.8 and JIRA.Issues.IssueFieldModel is undefined in the view screen. Has anyone else seen this?

[Wim Deblauwe]

Hi,

Building upon Nikola's answer to disable one custom field for inline editing, I found that I had to do the following:

I managed to make it work, but I had to do some minor adjustments. I have put the code in a separate .js file and modifying it to look like this:

function disableInlineEditForCustomField( customfieldId )
{

    if (typeof JIRA.Issues === 'undefined')
    {
        return;
    }

    var _this = this;
    JIRA.bind( JIRA.Events.NEW_CONTENT_ADDED, function ( a, b )
    {
        _this._disableInlineEditForCustomField( customfieldId );

    } );
    this._disableInlineEditForCustomField( customfieldId );
}

function _disableInlineEditForCustomField( customfieldId )
{
    var view = AJS.$( JIRA.Issues.IssueFieldUtil.getFieldSelector( customfieldId ) );
    var disableFunction = function ( e )
    {
        if (AJS.$( this ).is( '.editable-field' ) || (AJS.$( this ).is( '.editable-field > *' )))
        {
            console.log( 'disabling inline edit for ' + customfieldId );
            view.removeClass( 'editable-field' );
            view.removeClass( 'inactive' );
            view.attr( 'title', AJS.I18n.getText( "at.celix.jira.plugins.zones.fieldDisabled" ) );
            view.find( '.icon' ).remove();
            view.unbind( 'mouseenter' ).unbind( 'mouseleave' ).unbind( 'mousemove' ).unbind( 'mouseover' );
        }
    };
    if (view.is( ':hover' )){
        view.delegate( '*,', 'mouseover', disableFunction );
        view.hover( disableFunction );
        view.mousemove( disableFunction );
    }
    else
    {
        view.hover( disableFunction );
    }
}

Then I added the js file in the atl.general context by adding this in the atlassian-plugin.xml:

<web-resource key="jdvp-js-css" name="JDVP JavaScript and CSS">
        <context>atl.general</context>
        <resource type="download" name="database-values-plugin.js" location="js/database-values-plugin.js"/>
    </web-resource>

Last step is to call the method from the view velocity template:

<script>
	jQuery( function ()
	   {
		   disableInlineEditForCustomField('${customField.id}')
	   }
	)
</script>

Thanks a lot Nikola for your script!

regards,

Wim

PS: I would have added this as a comment on his answer, but comments cannot be longer then 2000 characters it seems.

[Nikola ILO]

Hi Wim,

this is quite similar on how we are doing it.

You probably will want to replace AJS.I18n.getText( "at.celix.jira.plugins.zones.fieldDisabled" ) with your own message ;-)

regards,

Nikola

[Wim Deblauwe]

Ah, yes. Indeed. Did not notice did. I must say that I am using your code without understanding it, so I just copy/paste it :) Thanks for the tip.

[Brent Webster]

Wim: I'm new to the stuff and I'm using Jamie's Behaviours plugin to create a customized subComponent field that depends on the value of the Component field -- it works but now all inline editting is disabled. Can I include your code as part of this specific behaviour code for this field. Or where do I setup it up to make it a more general solution. Thanks in advance from a newbie.

I wish Atlassion would put out explicit application notes when good stuff like this is document rather than me trying to distill it from all the answers and comments currently written.

[edwin]

Hi guys,

It's great to see such a lively discussion around our new features in EAP! Thanks for all the comments - great feedback for us here. Certainly hearing you guys loud and clear, and just thought I'd try to give some answers around what we're currently planning and why.

Firstly, we approached this feature with a clear understanding that today's user interface has some challenges. We set off with the goal to simplify, and to speed up these interactions. At the same time, as Jamie mentioned, we noticed that majority of updates to issues were actually singular edits - an update to an assignee, a change to a priority. A full page change to editing (or a full dialog) was becoming significant friction to keeping issues in JIRA up to date (especially for those who are working through a set of issues). This feature is one on a long journey of UX improvements that we have started since JIRA 4.0, and will continue beyond 5.1.

Now, let me try to address some specific concerns:

• Will this break existing behaviour?

The short answer is no. We have developed this with the capability to switch off inline editing (globally) which will restore existing behaviour, including any impacts this may have on plugins. So rest assured that we're not going to force significant rework for plugin writers.

Furthermore, our immediate plan for inline edit is not a complete removal of the "Edit" screen as we understand in JIRA today even if inline editing is enabled. The current screen method allows for editing of fields that are driven by a screen configuration - which may not necessarily map to what our customers desire to appear in the view of an issue.

• Notifications

Right now, a notification will be sent with each inline update. We have built this in-line editing feature with eyes wide open to the challenges of "notification-spam" that may occur as a result of this. Behind the scenes, we have played with many options that we hoped could reduce that friction whilst accomplishing the goal of not generating more notifications. This includes looking some form of "edit-mode" that you can enter to as you view the issue page. However, as we tried different things, we asked ourselves why inline editing was a feature we wanted to pursue - we really wanted a friction-free environment for quick, singular edits. Our testing, investigation, and feedback all demonstrated that the most intuitive, friction free way to quickly update fields was an in-place, singular edit. For the case of quick singular edits, notification batching didn't necessarily apply. Having said that, we are well aware of that having many notifications from JIRA is a real concern - we do have some potential strategies for this, and will potentially address this in the future.

• What about a "mode" of some form to edit?

As mentioned above, we certainly have looked at different ways we could design that experience. In fact, we began implementation on an approach quite similar to what Dieter and Jamie suggests - as you began editing, you can change multiple fields and save them together via a "Save" button that was for the whole page. We tested this approach with our users, and received feedback that led us to change direction.

• What about security?

This is also a good question and one that we've given much thought to. To ensure that we do not break any security / permissions schemes, the only fields which are "editable" on the view issue page will be those that exist on a user's edit page. As for confusion for non-editable fields - this actually falls into a bigger category of fields / items on the view issue page that will not be editable - these can include fields like created date, updated date, a status which requires transitions, etc. We are looking ways to address some of these.

• What about issue navigator?

As mentioned, this feature is one in a grander vision of change for JIRA's user experience - and we do have ideas for the issue navigator as well, with the goal again to reduce that friction of getting to issues and working with them in your day to day interactions. Stay tuned on this one.

Lastly, I'd like to say that since we've began dogfooding this feature, we've seen our interactions with JIRA sped up significantly as we worked with issues every day - especially in those long boring triaging or scheduling meetings. We've been really stoked by this feature, and hope that you do too!

Thanks again,

Edwin

[Nic Brough -Adaptavist-]

>the only fields which are "editable" on the view issue page will be those that exist on a user's edit page

That mostly fixes my main concern about it. As I said before, in-line editing is definitely a desirable thing from a user perspective, the faff of having to open up a screen every time you want to change one thing is definitely not optimal and this change is a great idea.

Of course, it's still going to look wrong - having some fields that can be edited and others that can't. It's especially bad for my users - the basic case is below (and it's used a *lot*):

• Team A uses Jira for their process
• Team A have a "Red/Amber/Green" status field (I'll say RAG from now on)
• Team B needs to feed information to Team A, so they raise issues in Team A's Jira project
• Team B is not qualified to set RAG, but Jira doesn't do field-level security, so
• We removed RAG from edit screens, and put an "edit RAG" down as a transition which
  • goes through a screen with RAG on it
  • is limited so that only Team A can use it
• Net effect - Team A can set their RAG and Team B can't.

Now, inline edit arrives. Team B is fine, they can edit all the fields they should do, although they will ask why there are fields they can't touch. Team A will like the inline edit too, but they won't be able to edit their RAG, they'll still have to go through into the transitions.

That, to my mind, is still quite broken. Ok, we can educate people around it, but it still looks silly.

It's very nice that the inline edit can be turned off - we may have to use that.

I am still concerned about the email spam too, but most of my main clients probably won't notice - they've already got used to the volume of mail from Jira and simply turned it off or email-filtered on the client side. Except where I've managed to get them to use "aggressively silent" notification schemes.

I'm not really qualified to talk about the plugin side, I've not written anything this would affect.

[Norman Abramovitz]

I want to thank Edwin for his response. I hope in the future releases some of the issues noted here can be addressed.

[Ashton Treadway]

Edwin:

Thanks for the answers. My question pertains specifically to Time Tracking.

We are having adoption issues with time logging because of resistance to the pop-up Time Tracking window. We're getting a lot of requests for a simple in-line edit where people can enter the time spent (like 3h), versus the entire pop-up window.

In the EAP, it looks like even with in-line editing, clicking on Time Spent in a GreenHopper card still brings up the pop-up window.

Someone made a suggestion that in-line editing be something that can be disabled or enabled selectively; I'd like to advocate for being able to control it on a field-by-field level, and suggest that this could be handled in the Screen configuration with an "Inline Edit" checkbox that specifies the edit behavior for that field on that screen.

[edwin]

Hi Ashton,

Thaks for sharing that with us. When we looked at inline editing, we considered whether we can include functionality like time logging. Unfortunately, time logging was a slightly more involved process in JIRA when compared to just editing a field (e.g. putting in a new remaining estimate, putting in a worklog description, etc). This necessarily required a bigger interface than what the "inline edit" model allowed. Based on that, we decided that we were not going to allow an "inline" way to log time in this release. Having said that, this is certainly one input we'd take into consideration as we continue to improve our interface.

As for configuring inline editing on an individual field by field level - is there any other particular reason why you would want this other than an ability to have an inline way to log work?

[Ashton Treadway]

Edwin: in our experience, people break broadly into two camps when it comes to time-tracking. Either they like having all the details (the pop-up), or they just want to quickly note how much time they spent on an issue (simple inline edit: 30m, 2h, etc). We have far more of the second than the first.

To separate this from the larger inline-edit issue: maybe what we really want is an inline "quick entry" version of the Time Tracking dialog: click the field, enter a time and a brief log, and click to commit.

One definite use case we have is people wanting to quickly log time along with a comment on an issue, which removes the need for a separate time-tracking worklog.

Insofar as configuring editing on an individual field-by-field level: we'd like to have this because it would allow us to customize UI for a team's preference. If the team prefers to edit using dialogs, we can give them that; if they prefer to edit inline, we can give them that.

[Jobin Kuruvilla [Adaptavist]]

The inline editing is going to a be a popular one for sure to a set of people but I agree that it is going to make things difficult for plugins like Behaviors plugin and customizations involving Javascript hacks.

I would like to have both options. Maybe it is best to do it via a siwtch? Turn it ON/OFF at will for different installations or maybe even at a project level?

PS: Good point about notifications.

[Wolfgang Jia]

Regarding dependences across fields, if jira can have directly followed relevant field set to editable when the current field finishes editing and thus again and again until all relevant fields get updated one by one in sequences. I think this may sovle the problems.

[Nic Brough -Adaptavist-]

Oh dear.

That could render Jira completely useless for a lot of users. A lot of people were disappointed by Atlassian's refusal to support field level security, and the work-around for that was to move edits of "controlled" fields into the workflow. If you can suddenly edit fields inline, that's the whole thing broken.

This will certainly break it for my current main client, unless it can be enabled/disabled by field. Or we get field level security sorted.

[JamieA]

That's a great point, I hadn't even considered that. I guess there will be an off button for inline editing...

[Jobin Kuruvilla [Adaptavist]]

@nic Always a minute ahead :)

[Nic Brough -Adaptavist-]

I posted too quick as well.

I haven't actually looked at 5.1 yet. I've just realised a possible fix - if the inline edit is only enabled for fields on the "edit" screen in the screen scheme, there's no problem...

[JamieA]

You would think it must be... although I can see users being confused... "why can I click and edit this field but not this one?"

[Nic Brough -Adaptavist-]

Yes, that's another thing we'll have to add to the "education" list.

[Norman Abramovitz]

Personally, I do not like the single line edit since it adds more complexity. My feeling we need different screen types to represent the user's development process unrelated to state or status changes. If you need a screen to edit a single edit then have a screen like that because it matches how your development process works. If you have dependency between fields then those fields would be on the screen and underlying logic will nort be broken. I am suspecting the dependency between fields will be lost (or broken) since it goes against the concept of single line editing. I can understand why it is being added since most of the default fields have no dependency.

The new interface is clumsy as well. It should be more like the screen is editable period. If you change something and move away from the page it should protect you. You can have a save button that gets highlighted when something changes. No special click to get things started. No lost of functionality related to dependencies between fields and the system tells you if something changed if the save button gets activated.

[JamieA]

I marked this as correct because it's the answer I like most (ie most similar to my thinking). But i'm unmarking correct it just in case it puts people off joining the discussion.

[Nic Brough -Adaptavist-]

I pretty much agree with it too. I like the idea of being able to edit fields directly, it's a good goal, but I don't think it's been thought through in terms of impact on the behind-the-scenes stuff (email, workflow, field protections, etc) or interface.

It feels "wrong" as it is at the moment, and Norman expresses it better than I can.

[Renjith Pillai]

• Inline editing in issue navigator is something which I was badly looking for. For organizations who are so used to Excel, transistion to Jira is hard and the biggest complain during those times, and even now, is that during meetings quickly editing a list of items is real hard in Jira. They keep falling back to Excel strategies due to this limitation.
• Regarding notifications, I always wanted an user level setting (like in confluence, when we say 'minor' edit) which can be turned on and off (may be a small button on top). This really helps in avoiding notifications. Or while in Issue Navigator editing, this can be completely turned off with a warning.
• Regarding dependencies across fields, when the inline editing comes, those rules set by behaviours plugin will still hold good right? Like in your example, single cell editing should throw an error when due date is set. And the user should set the 'reason for due date' first and then the due date.

[JamieA]

Agree that editing in the issue navigator would be popular.

> Like in your example, single cell editing should throw an error when due date is set. And the user should set the 'reason for due date' first and then the due date

That would be very cumbersome for the user... they'd need to cancel their edit, set the other thing, then do another edit.

And for the example when you have a select list with a value "Other", when you select Other you need to fill in some other field, that would be impossible.

[Valentijn Scholten]

@Jamie, what if you want to force that the "Reason for due date" is only populated when a due date is set?

It would become a chicken and egg situation if you try to force the correct order in which fields need to be populated.

[JamieA]

Yep exactly, that was what I was trying to say in my example above, but you said it clearer. Sometimes the issue edit can only make sense, according to your biz rules, if two or more fields are edited together.

[Valentijn Scholten]

Anybody had a chance to see how notifications are handled in 5.1EAP? I doubt there will be some kind of batching/summarizing/merging. I wouldn't be surprises if there's gonna be multiple emails. Or maybe no emails at all, only for edits done via the edit button (old/current way).

[JamieA]

In the EAP at an rate it sends a mail for every field edited inline!

[Dieter]

That's why i'd like it if the user could inliine edit multiple fields and then hit something like an update button.this would cause all the edited fields to be updated in one transaction causing one notification event. But it looks like Atlassian doesn't want to do it that way since the update button is related to the field. Not a good decision IMHO

[JamieA]

Yeah agree, that's what I was getting at in the comment to my question. Press e or click one field then they all become editable, then only one notification event sent.

> since the update button is related to the field

No reason why it needs to be though....

[Igor Sereda [ALM Works]]

I'm all for this new feature, and the field editing on the Issue Navigator, when it becomes available. Inline editing has been one of the top voted features for our Structure Plugin, and we've seen customers really happy when we had made it possible to edit the displayed values right in the Structure Widget (which looks like the Issue Navigator). It's great to see JIRA catching up ;)

With regards to the frequent notifications, it's great if there's already batching of the notifications -- I'm looking forward to the API for that, which could be used by plugins. We're currently do our own batching as much as possible.

Screens vs. inline editing -- the concern is very real, I guess. We've had quite a few theoretical discussions at our company about this, "editing state" vs. "transitions". When you edit state, you just change some values, you have "old value", "new value". When you make a transition, you apply a specific operation, which may have parameters (like new values for some fields - but may be others as well). Both types of changes have their pros and cons, both technically and from the user perspective and they are very different in the possible features.

So inline editing is "editing state", but the "Edit" button is editing state too! I don't see how inline editing might be worse in this sense than just opening Edit screen and changing that value and pressing Submit.

Transitions are different - but JIRA has only workflow transitions, which are tied to workflows and statuses, which can get very cumbersome. But in theory you could disable Edit button and do everything through transitions. I wonder how many companies do that.

[JamieA]

> So inline editing is "editing state", but the "Edit" button is editing state too! I don't see how inline editing might be worse in this sense than just opening Edit screen and changing that value and pressing Submit

Because, when you click edit, all of the fields are available to be validated, which many people do via javascript or my plugin. All the more so given that jira is pretty weak at providing hooks to do a server-side validation on edit.

I wonder if all the people that have javascript in the field configs realise they are going to need to rewrite it all.

[Igor Sereda [ALM Works]]

jira is pretty weak at providing hooks to do a server-side validation on edit.

Exactly! That's what I meant when I suggested that validation-centric approach should use transitions -- workflow transitions since they are ready, but I think there might be a plugin that provides "edit transitions". Maybe that could be the next Behaviors?

Good point about javascript-powered fields - I think Atlassian should highlight that in Developer's Release Notes.

[MattS]

Just getting round to rewriting hundreds of little pieces of JavaScript that various admins had pasted and tweaked to change JIRA field behaviours. Totally unscalable, Behaviours is the way to go, I thought. But then I remember the inline editing problem affects the plugin as well. Sigh. I wish JIRA had scriptable field-level behaviour

[Valentijn Scholten]

I haven't had a chance to look at the single edit thing, but it will make it complicated to keep all Behaviours Plugin functionality in place.

One direction could be to hook into the atlassian javascript used for making fields editable.

In the example above, when a user sets the due date field, the behaviours plugin would also make the reason for due date field editable. It should then bundle those edits and send them to jira together.

Basically would require a rewrite of a big part of the behaviours plugin I suppose.

[JamieA]

Yeah, huge amount of work :-(

[JamieA]

There is a version of the behaviours plugin that supports jira 5.1 now. At the time of Johan's comment there was not. Can't guarantee this bug is fixed though... don't remember.

[Johan Corveleyn]

I'd like to mention that I've done some successful experiments with the behaviours plugin with 5.1.3. But in my case inline editing was not relevant, because I only needed behaviour during certain workflow actions (the behaviour had a condition to only be active on a certain workflow action), and that worked fine.

One thing that didn't work well was setting the assignee field (in a server validation script). The ultimate goal was to "preselect" the assignee to be the reporter (on "resolve issue" action). I tried several variations like:

FormField assigneeField = getFieldById("assignee")

assigneeField.setFormValue("testuser")

Or:

FormField assigneeFieldField = getFieldById("assignee-field")

assigneeFieldField.setFormValue("testuser")

But that didn't work well -- it would literally put "testuser" in the field, and not the full name of the actual user object like if a normal user selects testuser manually -- and the submit of the form failed (the "assignee" field is not a simple input or select field, there is some javascript foo behind it).

In the end, I went back to using javascript in the description of the assignee field. I found a good snippet on how to set the assignee in javascript here.

It might be nice if the behaviours plugin could also set the assignee with some similar javascript, exposed through some explicit API for the server validation scripts (e.g. issue.setAssignee(userId)), instead of handling it as a simple FormField.

[JamieA]

> does this mean that the plugin is compatible with 5.1.4

Well, nope, but if it works for you then maybe. I have not even done this much yet. Finally got round to starting this process last night, but it's going to take time...

[Mizan]

Hi Jamie ,

I installed behaviours plugin in 5.1.4 and all the modules were succesfully enabled , now if i disable inline editing does this mean that the plugin is compatible with 5.1.4 ?

Thank you

[Alan Alan]

Hey @Jamie,

Your behaviours plugin is very useful for us, and it is why we have held our plan to upgrade to JIRA 5.1, if it doesn't support behaviours plugin. Wish your new upgrade coming soon :)

[JamieA]

Not saying it definitely won't happen... as soon as I scope it out I'll get back here with the verdict. I think there is definitely a space in the "market" for something client-side that can control fields. The "javascript pasted in the field config description solution" wasn't sustainable. Just not sure if there is enough stability in the client code to warrant the effort. But, like I say, will post back soon.

[Christian Czaia _Decadis AG_]

Thanks for your response Jamie,

I can absolutely understand your problem. If you decide not to maintain the behaviours plugin maybe others will...since you published it under a BSD license. It's a great plugin and I haven't found anything like it. I'll pass the source code to our developers in case it'll become the "casualty" mentioned above :-)

[JamieA]

Hi Christian,

I was always planning to keep maintaining the script runner plugin, that was never in question. I still have not decided on the behaviours plugin. I need to do some research on how feasible it will be, specifically, if there is a method of programmatically making a field editable, and also if it appears that the javascript for the various methods of entering an issue are converging (create issue, and greenhopper new card). It depends as well on how many people have disabled the inline edit, or are willing to disable it if that's what it takes.

Unfortunately I'm finding less and less time for unpaid work, and the behaviours plugin gives me disproportionately more work for the amount of users than script runner, so if there has to be a casualty, that will be it.

[Christian Czaia _Decadis AG_]

Hey @Jamie,

now with JIRA 5.1 out what do you think about it? Are you planning on maintaining your plugins?

Cheers Christian

[Valentijn Scholten]

Just to share a possible solution for those who aren't aware of this solution:

I was lucky to have only two usecases for the behaviours plugin which I used to have some kind of field-level-security.

So I replaced the two behaviours with two global workflow transitions.

These global transitions are available in each workflow step. I configured them to have themselves as the target step, so using the workflow transition doesn't change the status of the jira issue.

Each transition has its own screen with a limited set of fields that can be editted in this way.

Each transition has the same conditions as the behaviours used to have, to only allow access to the new screens for users with the required roles/permissions.

[MattS]

Using -1 as the end step to make a global transition return to the start step is neat

[Renjith Pillai]

Another thought. Previously I could have restricted the fields that users can edit by allowing an update on such fields using a restricted workflow while I can safely show the field in the View screen of the issue.

With this inline editing, that functionality seems to be completely broken.

[JamieA]

According to Edwin's comment, it will only allow inline edit of fields that are on the Edit screen.

[Renjith Pillai]

Okay, then it should be fine.

[Dana Frost]

I understnd the desire for field by field editing. I just wish that along with field by field edits, Atlassian would also provide field level hooks (like the ones you can do in 4.x with behaviors). But since this is not supported, is seems any plugin that uses the edit/screen to determine the field's edit (copy from one field to another, clear it, etc) may no longer work.

So, the claim is, that turning off this "Turn off Inline Edit" will maintain the same behavior. I suppose that will give some plugin devs the time to see if they can handle it. But I know some plugins are already not working do to the "dynamic" change in the forms now (in 5.0) when you create a new issue.

Bottom line, I feel that it will continue to be hard to upgrade your plugins with changes of this level are going into 5.0/5.1 etc. Not, that thas was not a problem in the past :). I just appreciate the work it takes to stay recent with these new changes.

[Valentijn Scholten]

@Jamie@Dieter It could be sufficient that if not all fields become editable at once, but you start with one and then can make more editable. For example you make Due date editable and populate it (but don't press update yet) and then make "Reason for due date" editable and populate that as well.

Hmm, but while I am typing this, how can we combine the two edits. Maybe there should be only one update button?

Remember, I don't have 5.1 EAP installed here, so I hope it makes sense.

Good point to poke atlassian about this thread jamie.

[JamieA]

Hi Dieter, yeah, that's a good point, but you wouldn't lose anything over what you have now. Also, the select list options could be loaded in the background even after the fields become editable... it should not take long to load even thousands of options, so long as you're not loading all the page chrome, which seems to be the major bottleneck. And if you do have thousands of options, sounds like you could be better off with an autocomplete type thing like in the sql or sql feed plugin...

[JamieA]

BTW I tested the "poke atlassian" button, if only because the designer of this feature might be interested in some of the comments on this thread.

[Dieter]

Hi Jamie, for users with many customfields loading time may become annoying if they just want to change one or two fields. I don't see this problem for screens with just some fields but e.g.i have some projects with really large select lists and if someone just wanted to edit the summary, loading these lists would cause significant delays. Surely this is not representative but for me 2000 users work that way. So if the fields would become editable only on demand (e.g. Click), i guess this is what would give them the best performance. I completely agree with you that there should be a save button at it's fixed place to save the changes.