Big Sur mail plugin once again

The mail plugin once more.

Could someone at DT please check if they’ve got the time:

  • completely wipe disk of a test machine
  • new macOS Big Sure installation
  • new DT installation
  • login as regular (non-admin) user
  • start DT
  • start Mail + setup some mail account (required to proceed I think)
  1. Are the add-ons installed automatically? (I can’t remember if this occurs)
  2. Do you get a request by DT or macOS to enable/manage the plugin in Mail?
  3. Do you get a request initiated by DT or macOS to allow full disk access?
  4. Does the mail plugin show up under macOS Mail->Preferences?

I’ve found none of the above occurs (except perhaps point 1) although the manual repeatedly states use of the plugin is advised to enhance importing e-mail. I went through several topics and troubleshooting in the manual to try and resolve it, but if above is reproducible I would consider that a bug or at least illogical behavior. I presume most users will not go looking for full disk access or start deleting library folders to troubleshoot on their own, nor should they ideally be required to read the manual (although it’s very well written IMO).

It appears re-installing the plugin is described in the manual on page 176, which more or less seems to make it a re-install ‘by default’ for some. I don’t think re-installing a plugin should be necessary if it could be avoided in the first place, but to make matters worse, in my case re-installing is impossible as the box is greyed out and DT reports the plugin is already installed.

What am I doing wrong? Is installation of the plug-in completely automatic? Does or doesn’t it require full-disk access?

TL/DR; mail plugin could to be more complicated than perhaps necessary

Some of this needs to be answered by DT themselves, but I’m going to try and help you troubleshoot in the meantime.

To the best of my memory, the answers to your questions are:

  1. the add-ons are installed when you select to do so; from there on, installation is automatic, but my memory is that I have had to then activate the plugin in Mail manually (via Mail, Preferences, General, Manage Plug-ins…)
  2. no
  3. yes, no, or maybe. My experience with macOS is that it will often times ask for the necessary access, but occasionally either forgets or dismisses the dialogue before I get round to making a choice.
  4. yes (if, in preferences, you select General/Manage Plug-ins…)

Re. Full Disk Access: DT3 itself requires FDA to work properly. Mail and/or the Plugin do not. In Automation, I have both DT3 allowed to control Mail and Mail allowed to control DT3. I cannot tell you whether that is due to the Plug-In, or was something I set up along the way because I use scripts in both programs to perform actions with the other.

If the Plug-in is not appearing in Mail (under Preferences/General/Manage Plug-Ins…), however, any thoughts about necessary access are moot. This can happen (maybe Mail wasn’t really closed when the Plug-In is installed? It was a full moon and a wolf howled at the wrong moment, etc.)

Does this post help you?

Again, I’m aware I haven’t addressed the question of user-experience in my post - I don’t think that is for me to do; I don’t have the necessary metrics available (number of users having trouble vs user base; conditions attributable to DT3 vs to macOS).

1 Like

Check.,No wolves were howling :grinning:

But what I intentionally used and described was a highly standardized surrounding (new installations) and as such a highly reproductive situation for DT to test. Only the hardware could be different, but I think that shouldn’t influence macOS behavior in this case (although that could be the case of course).

Did you perform the steps above or is what you desribe your experience in the past without new installations following a wiped disk?

Thanks. I’ll check and if that works that would be nice.

But my main point is that those steps obviously needn’t be necessary if avoidable somehow (and perhaps they aren’t). The question wasn’t meant as negative critique to be clear, but as feedback that a process appears to be behaving in a way that I think might be improved (if confirmed and possible to improve that is).

The question (and the reason why I set a ‘bug report’ tag) therefore is if this behavior is standard and could be avoided. Users likely aren’t aware a plug-in isn’t running, if it isn’t running. And likely will not report problems unless they discover in the manual that full disk access is required etc. and check if it is. But users could also be actively nudged and, as far as I know, it’s possible to programatically check for example if Mail is running. So if it is necessary that Mail is closed during installation, DT might check and ask a user to first close Mail before add-on installation will proceed. IMO that’s a better way to handle installations, as a user that didn’t close Mail if it should have been closed will be puzzled by the reason why the plug-in doesn’t show.

It’s my memory of my experience following a fresh install (that is, on a wiped disk); I don’t have a test rig, so it’s nothing I can test en passant.

I understand this; I’m only doing the “help @Solar-Glare personally” bit, the rest is for DT :slight_smile:

DT does that; life experience says closed programs sometimes aren’t, though (eg program appears closed, task manager shows it alive and kicking); I don’t have the knowledge to say whether occurrences such as those can be detected or not, or might influence an installation. Just kinda guessing :slight_smile:

And I sincerely appreciate your help! My question was somewhat ambiguous, as indeed I’m trying to figure what to do and was thinking about the reasons why I need to do them.

Likewise. I agree it’s probably the developers that can explain what might be going on the best and what is and isn’t possible.

1 Like

That, btw, means I don’t have a clue but want to be seen to be trying, at least :stuck_out_tongue_winking_eye:

1 Like

The Mail plug-in is not automatically installed. After launching the app for the first time, the support assistant is opened showing the Welcome screen and some setup instructions (e.g. to install add-ons).

But after installing the plug-in it has to be enabled in Mail’s preferences (as described in the Install Add-Ons… panel) in the latest macOS releases. Features requiring full disk access or automation should display an alert, either by DEVONthink (in case of full disk access, e.g. importing Safari bookmarks) or by macOS (automation).

Denying an automation request is actually not recommended because macOS does not even add a disabled option to System Preferences > Security & Privacy > Automation > DEVONthink 3 for the app, meaning that you can’t customize this afterwards anymore.

Thanks for the feedback!

Could you check if my above steps work for you, assuming you’ve got a test machine that you can easily set-up as new. If that requires a whole bunch of work and you don’t think is appropriate to test my questions, I perfectly understand of course. That choice is obviously up to you.

That said, to my recollection (and of course I could be wrong), I haven’t denied any requests, but simply wasn’t offered something to deny.

I’ll try @Blanc ’s suggestion and remove the mailbundle as described in the linked post. Is that solution indeed the best way to try and resolve to your knowledge? I’ve set full disk access to be clear and DT reports the mailbundle to be installed (greyed out - installed).

Unfortunately no such machine and way too much work, I’m sorry.

Hi Solar-Glare, are you seeing the “Manage Mail Plug-Ins” button in the Mail preferences pane (at the bottom left corner)?

There is sometimes an issue where that button is not shown even after the mail plug-in is installed. You have to click that button and click on the box next to “DEVONthink_BigSur.mailbundle” to get it activated.

Thank you for your anwser.

No I didn’t see it.

As I already set full disk acces, I followed the mentioned steps by first closing Mail and DT, removed the mailbundle from the appropriate library folder, restarted DT, installed the Mail add-on again (no longer greyed out), restarted Mail and then did see the manage plugins button.

That’s exactly what happened. But it happened on a device that was competely wiped and used a new installation of macOS Big Sur and DT3.

It’s hard for me to analyse why I couldn’t see the ‘manage plugin’ button in Mail and @cgrunenberg doesn’t appear to have a test device to reproduce what I described to analyse it. I personally wouldn’t be surprised that full disk access is required before the mailbundle is installed and granting acces afterwards doesn’t work unless the bundle is reinstalled.

What I find concerning though, is that other users appear to report such behavior as well as you indicate (‘There is sometimes an issue’). What’s causing that ‘issue’? In the end, it likely means people think they installed the plugin but in fact they haven’t. The mailbundle is there, but Mail doesn’t use it.

IMO informing users with information screens or a text that tells them to ‘enable’ something is confusing if some users are unable to enable it as the ‘manage button’ sometimes isn’t presented by Mail.

If DT cannot itself check if full-disk access was granted like described by @cgrunenberg, nor whether the ‘manage plug-in button’ is presented by Mail (also see my last sentence below), an easy and simple solution might be to provide a pop-up every time the ‘install add-ons’ button on the add-ons dialog is pressed. That pop-up could explain the user has to manually check whether full-disk access is granted, why it’s important, where to check for that, what the ‘manage plug-in’ button in Mail actually looks like and see if it’s indeed there and the plugin is activated.

Now, you might ask, isn’t a pop-up an over-intrusive way of informing users? I certainly agree, were it not the add-ons screen is likely visited once perhaps twice. It’s not a menu a user goes back to unless some problem arises. If the step to grant disk access is that important and DT cannot check if it was, IMO a user should be ‘taken by the hand’ to check for it manually.

An even better solution in the end might be if the plugin-in somehow provides feedback to DT that it was activated. If it wasn’t, the add-on shouldn’t be greyed out and reported to be installed I think, as the mailbundle might be ‘installed’ in the library, but Mail doesn’t use it necessarily if my observations are correct. But that requires a method for the mailbundle to provide feedback, and I don’t know if that’s possible.

@BLUEFROG @eboehnisch

1 Like

I asked because I had the missing “manage” button problem too and it was a MacOS thing rather than a DEVONthink thing…

See: Can't use Devonthink Services in Mac Mail.app on Catalina - #6 by jbhutt

From @BLUEFROG:
This is an Apple issue. You can try this…

  1. Quit Mail.
  2. Open Applications/Utilities/Terminal
  3. Paste: sudo defaults write “/Library/Preferences/com.apple.mail” EnableBundles 1
  4. You’ll need to enter your administrative password to do this.
  5. Type: exit and quit Terminal.
  6. Launch Mail and check the Preferences > General.
1 Like

That might very well be and perfectly understand that it can be. But in the end that mostly means cause analysis can be more difficult and a more definite fix is less likely as the DT staff obviously cannot change macOS.

If I understand correctly the current method to explain users who are (I presume sometimes unknowingly) confronted with this issue, seems to be providing them with information somewhere in the general pop-up at start-up and an instruction that cannot be followed as it requires a button to be visible that isn’t.

But reporting something as ‘installed’ without it being active is confusing to me and likely to others as well if I take at least your and my question about the plug-in not working into account.

Whether it’s the trouble of looking into that or my suggestions is upto the DT staff of course,