I am unable to create a report. When I click on the triangle under the reports tab "create" is not an option. I can view view reports or schedule reports. HELP!

Are you an admin user or a regular user?

If you are regular user and some Role assigned to your profile has no access to edit Reports then you will not be able to create.

Additionally you can double check if there is any customization which eventually had drop of the create option.

Possible customizations places:

custom/modules/Reports/clients/base/menus/header/header.php

custom/Extension/modules/Reports/Ext/clients/base/menus/header/header.php

Regards

Hello André Lopes,

Further to the above I am wondering what the customisation would  be to actually hide the create button?  I guess I need to add the directory and create the file, then add the code to the file?

 - Cloud Enterprise 10.1.0    (but I have a local Dev instance so can access the custom folder to test)

I see in Roles that Create is the only option not available to restrict. We would still allow editing the serial number.

Specifically we have a custom Serial Number Module which [depending upon another job underway now to import those automatically] we will eventually want to hide the create option as an extra way of avoiding duplicates and also of forcing the ID to also be the serial number which we do via the import:

Custom/Modules/S_SerialNumber/  ?

Custom/Extension/modules/S_SerialNumber/ ?

It is far from urgent, just curious at this stage:-)

Thanks again Andre!

Glad folk like you are active on here too 

Luke.

Hi Luke Ridgway,

I have 3 comments for you to consider

1. The custom folder

Generally, every path which begins with root/custom/something/goes/here has an equivalent core version which will look like root/something/goes/here.

So to understand how to customise a file which might be located at root/custom/modules/S_SerialNumber/clients/base/menus/header/header.php, first go look at root/modules/S_SerialNumber/clients/base/menus/header/header.php (or if you don't have one for whatever reason, just look at the example Andre pointed at in root/modules/Reports/clients/base/menus/header/header.php

What you'll note is that the menu items there are stored in an array, and one of the items is the create option. So, if you don't want the item there, you can delete that item from the array.

2. The Extension folder

A weakness of the above strategy is that while it's fine if you're the only person making changes to a particular module, but what if you downloaded a plugin which also wanted to make changes to the same header? (I know it doesn't make sense in your example - its a custom module you made - but imagine this was the Contacts module?).

In that case, you'd need an approach where multiple people might want to customise the same piece of functionality, and the system would need to respect that.

That's where the Extension folder comes in. As part of Quick Repair and Rebuild, Sugar will combine the files it finds under the Extension folder into a single "Ext" file. When writing code for Ext, because you know it is going to be merged, you cannot simply declare the value of  $viewdefs[$module_name]['base']['menu']['header'] with an array without the "create" option. Instead, your code should iterate through the  $viewdefs[$module_name]['base']['menu']['header'] array until it finds the 'create' item, and then unset that key. That way in theory if other plugins had added items to the header array, you do not inadvertently remove them.

This is why Andre said customisations can be in either location - because they really can. Sugar will load the custom version first and then the Ext afterwards. You can learn more about all of this here: https://support.sugarcrm.com/Documentation/Sugar_Developer/Sugar_Developer_Guide_10.0/Architecture/Extensions/

3. Is this the right approach anyhow?

A more important question is: is this even the right solution? Depends upon the business rules, and your users.

All of the above is just visual. Anyone who knows the URL (by trying to create another record for example) could still create a SerialNumber record - this just makes it a bit harder by hiding the option. If the cost of records being created manually is high, I would suggest instead thinking about doing the above, and implementing something a little more definitive as a backstop - e.g. a before_save logic hook which checks for imports and errors out otherwise / a validation.

Hope this helps!

Adam

As I previously mentioned the customization would be in Reports module.

André Lopes said:

custom/modules/Reports/clients/base/menus/header/header.php

custom/Extension/modules/Reports/Ext/clients/base/menus/header/header.php

I suppose you are an admin user, so Roles should not affect you.

Wow...  thank you Adam Frank!   

I have saved your reply offline, studied it, and noted the excellent information provided.  What a great community! Thank you for spending the time to explain it so in depth.

I get your points in 3. Is it the right approach?    We are currently working on the automation of the SN import to sugar from our DB in the office.  If a user manually creates a sn, that sugar ID gives me a dupe error in the current daily manual sn import: as we set the ID to be the serial number in the import (.csv).

When phase 1 of the automation is done then as soon as a printer is 'born', it will appear in sugar.  So the need to manually create is gone, but can be done more accurately with sql query and that resulting .csv imported - should the need arise.  So 'hiding' Create button would actually do the job really just as a reminder I suppose. Sometime fake sn may be required and we don't care about the info for those, so having the url method may also be handy.   Therefore I will look into the extension when we get to that point.    Though I know I will get "Luke, I can't create a serial number!" messages !!

Your reply actually clarified a deeper understanding of the architecture, even though I am sitting through some sugar uni tutorials and reading alot of the developer guide, I think in haste it is tempting to ask 'how do I do this' to get it done and move on... but for longer term improvements understaning the system on a deeper lever should bring a better quality result and actuakky speed up some development....

So all that to really say thank you!

Luke.

You're more than welcome - glad it was considered helpful