New Desktop - Cannot Change Workflow State (Cannot Add / Remove Field)

Hi.

The forum is not a good place to raise bugs.  It's not tracked by our support teams, nor can it easily be escalated or reported on.  Can you raise this via a support ticket?

Hi Craig,

Is there any more direct path for this, unfortunately with the reseller arrangement we first have to raise it with our reseller, who wants to witness the bug themselves and often doesn't have the technical competence to understand the implementation or issue, and then they have to raise with M-Files. With the number of issues with "New Desktop" this is going to make it time prohibitive - in half a day of use by one user we've found 5 bugs.

Cheers,

Matt

Unfortunately that is the official way forward.

This forum is a peer-to-peer support forum and, whilst there are a number of M-Filers here, it's not something that we can put proper processes around.

I understand your frustration.

Unfortunately that is the official way forward.

This forum is a peer-to-peer support forum and, whilst there are a number of M-Filers here, it's not something that we can put proper processes around.

I understand your frustration.

Thanks Craig - it would be really useful if there was a more direct bug reporting framework rather than going through an intermediary. I'm not sure if this is something that can be raised as a "request" anywhere, but if the website could include a bug reporting mechanism or even ticket raising it would be amazing. I imagine there's a fairly large community of users that have more technical expertise than our resellers, and would be able to provide timely and reproduceable bug reports through to M-Files if there was a channel for the information!

I understand the frustration, I really do.

At this moment in time our resellers have responsibility for first-line triaging of items coming from their accounts; they are closest to the implementations and have resources to reflect on whether these things are related to your implementation or software issues, for example.  Should the reseller need to raise these up to us then we do have an official support portal where they can raise tickets, and these are tracked according to various processes (as I am sure you can visualise, as it's the same in many companies).

Whilst in many cases this works very well, I do acknowledge that in some contexts this adds an additional level of bureaucracy.

Hopefully one thing you will see from this portal is that it is very good at what it aims to do - provide peer-to-peer support for implementation, configuration, and customisation issues.  It also is used to try to provide product-level support, at which point things sometimes do stutter; the community is simply not part of that official support process, so the impression that customers get is that doesn't work as well for this.  This is why I will always push people back to the official process; that is designed for product-level issues and requests, and has proper means to track and process such inbound requests.

That said: what I can additionally highlight is that many M-Filers (such as myself), including a number of product managers (such as myself), do frequent these boards.  Where you raise items like this they do often end up being by the correct people.  But that process is much less formalised than the official one, and it too has its own complexities and nuances.

Thanks Craig - really appreciate the considered response.

I tried to raise this one through our reseller today and have been told that they cannot raise an issue as they cannot support VAF extensions. Let me know if you have a suggestion - happy to provide any additional data if it will assist with this one.

Custom scripting is indeed beyond standard support terms.  They are correct.

That said, if there's a difference in functionality between clients then that should be explored.  Instead of sending you round in circles, I'll ping this to a couple of people internally.  I am not sure what's happening, and I don't want you to feel that I can definitely own this and get you an answer or a fix, but my feeling is that there's something worth investigating here.

Again: no promises, and I have no way to affect prioritisation of things in other PM's spheres, but I will send this link to a few people.

Actually: you say this is inconsistent.  That points to it being an implementation issue rather than a product issue (if it worked differently every time then it could be a product issue).

My suggestion would be to try to work out the difference in logic paths between when it works and when it does not.  There must be one.  Add as much logging as you can.  The full error stack should give an indication of the line of code which throws the exception; can you post that?

I don’t think there’s an error stack to show here - this is an M-Files permission item (not an exception), and on a given object New Desktop raises a permissions issue 100% of the time, and classic desktop raises the issue 0% of the time.

For an object I create from new in New Desktop it does not raise a permissions issue. So I think this is still a product issue?

Ahh, you said intermittent in your initial message, but that's not the case?  You can replicate it 100% of the time?

Can you also confirm the M-Files desktop and server versions, please?

Intermittent was a poor choice of words - I meant it does not happen for ALL objects, but for a given object it is fully reproducible. 

26.1.15632.8 for both client and server.

Few more details if they help:

the object has a property “total value” attached to it (it’s a default property). The property has no users set to be able to write to it (not “deny”, but nobody has permission to write). The workflow state transition I’m performing (from “Approved” to “Closed” doesn’t perform any action (neither workflow state has any script to execute). The value is only ever written by an event handler which runs on “BeforeCheckInChanges”.

Inside the VAF function it will set the “Total Value”, it uses  “startrequirecheckedout” and “endrequirecheckedout” (because the same code runs on multiple triggers). Within new desktop for a given object (ID124 if I need to find it for you!) it will always error, same object in classic desktop doesn’t have any issues.

Might you be able to share a small set of code that reproduces the problem with me?  I anticipate your code is probably quite complex, but if you can boil it down to something small that shows the issue then it would make it much easier to get in front of the right people.

Edit: I see that I used the word intermittent first, not you, so my brain may have jumped to some conclusions when I originally read your message.  Sorry about that.