Hi, could you help me with my project please?

[punkyard]

Hi,

I'm trying to build a DB of Stages for independent song-writers to share a list of small venues with which they could arrange concerts.

All the artists/Users will share a common list of Stages (with common info as: addresse, principal email)
but all informations about accounts and contacts would remain personnal to the artist and/or the members of his band/team.

I thought of a multiple-to-multiple link between the tables :
to one Stage could be added several accounts that would stay personal to each User
to one company Account could be added several Stages when one company owns several venues)
but I don't find a way to do it yet ..

The best would be to show the personal data of each artist in the Stage Entity - but I think I read somewhere that it's not possible with Espocrm.
The least would be to show the list of the Stages related to an Account, through the account entity.

would someone take a moment to think about this and share one's thoughts?
it could be very simple to put in place, but i just can't manage ..

thank you all

[shalmaxb]

Hi,

the approach itself is right (one stage can have many musicians, one musician can have many stages = n:n relationship). The problem in espoCRM wih n:n is, that by default only the field name is multiple linked. That means, that you can display the names of the stages in every musicians account and vice versa all musicians accounts in every stage, but only the field name will be shown.
If you want to display more information from either of these entities in the related one, you will have to code or use the extension "Link Multiple Inline Form" by Eblasoft (https://www.eblasoft.com.tr/product-...le-inline-form). This extension is not free, but does the job very well.

But even with this extension, there is no way to use the other fields than "name" for priniting (PDF) or Email templates out of the box. Neither you perhaps might know, that you cannot print the list view, in case you want any PDF or hardcopy lists of you records. In these cases you must use workarounds.

Here a screenshot from my contact`s entity, n:n related with two other entities. All customized and using the extension by Eblasoft. For the display of the fields in the related list, you can freely choose, which fields you want to show.

[shalmaxb]

yes, it is one contact in the artists work portfolio. This contact bought one painting (which is pulled from the main entity of total list of artworks from this artist) and with another relation the respective invoice is shown in the contact. Means, if you call the contact, you can see, which artwork this contact/client bought and the vinculated invoice with that sale. Vice versa, this contact is shown in the artwork detail view, wehre the work is marked as sold and showing the buyer (this contact).
In this view three different entities are shown (contact, artwork and invoice), but I related yet more for other purposes, that are not seen in this view.

[esforim]

Hi punkyard, I was saying that if you plan to buy the extensions Link Multiple Inline Form, you can try ask the developer to add a feature to make it work for you. They might add it or might not but worth a try.

[punkyard]

I get it now, thanks

[punkyard]

let me put it in other words, to make sure I describe things properly :
In my expectation ..

an artist will create a 'public' Stage in the Stages entity, every other artist can see (size of the stage, number of seats, town, country)

but every artist needs a personal company Account in Accounts entity related to that public Stage, in which writing down personal datas (negociated prices, contacts, phone numbers, ..)

so, every artist can see every stage, but only his own account related to one stage

[punkyard]

my first attempt, was to show personnal/private/hidden-to-others fields in the Stages entity
so every artist can create a public Stage, in which every artist will created hidden personnal notes in a personnal pannel (as in CiviCRM)
but i think I read somewhere that hidden/personnal fields were not possible in EspoCRM

[punkyard]

now, I start liking the idea of personal Accounts created by each artist aside of each Stage. The Account field would just have to be hidden on the Stage layout, right?
Though, could I integrate a button "Create new account" on the Stage page?

[shalmaxb]

Hi, I am not sure, if this ist the right approach. You will see, if everybody who wants to book a stage has an account, you will have a lot of tweaking, what the single user will be able to see or what has to be hidden. Complicated.
espoCRM is mirroring workflow from real world, where there is kind of hierarchy (one is the boss and there are a few others with certain tasks and rights, the rest are contacts and company accounts - I know it is a bit simplyfied), accounts are more for companies with which you work together and as far as I know, it is not meant to be a user account. Though you can bend the system to do that, but, as said, it will be complicated, I think.

I understand, that you want to create kind of an exchange place, where musicians/bands and venue owners could meet, all self organized by the different participants. I think, this will be possible somehow, but I don`t have an idea yet. But I will think a bit about it.

To integrate a button, you will need to code. There are several threads here and something in the documentation about it.

[punkyard]

you make me think shalmaxb ^^ thanks you

.. Artists don't book Stages through EspoCRM, they create an entry for each Stage, with its details - like an index.
Stages/Venues don't have access to CRM and don't book artists.
It would be a platform to help artists booking their gigs in alternative venues.

They are many little bars and restaurants, tiny theatres, associations (non-profit), that greet song-writers on their small stages.
But they are not listed. Sometimes the conditions are barely legal, but that's the working conditions of independent songwriters here ..

Alone, every artist has to spend a lot of time looking for venues like those, enter details, copy-paste, copy-paste, copy-paste .. make a call, send an email ..

With this index, they will be able to share their prospecting work, which can be filtered to find a venue, depending on its size, its city, ..
Simple thing in the end ^^

[shalmaxb]

Think about the following:

1. Either venue owners and musicians should be users of your app.
2. Create the different user groups and roles. In the roles there will be the tweaking in the end, and it will be a lot, be aware.
3. Well, a venue will have the venue group and a role, that only shows, what this user needs.
4. A musician will have the musician`s group and as well the specified role.

The role you can define in a last step. First organize the user groups. As nearly every other entity, you can create your custom adaption directly in the user entity. Create all fields, that are imaginable necessary. For field, that one usergroup should not see, you can use conditional field, groups of fields, you may put on panels in the layout manager, wher you have another possibility to hide or show, depending on user group or role.

In both groups you could attach persons, that belong to the main user of that group. For example: A venue has a boss and several other people, that belong to that venue.
Or musicians play in a band and only one is a registered user, the other members of the band you register like contacts, that belong to the band.
By relationships you can show them, where you need. I do it this way with galleries. There is an owner, but also e.g. a secretary. The secretary will be a contact, that belongs to the gallery.

Generally spoken, in databases it is in the majority of cases best practice, to separate the different (sub) database entities. In the example you would not give every band member an user account of his own, because normally that is not necessary. So you put all connected band members in another entity, in my case in contacts.
In the end you will have a number of entities, all separated and easy to maintain and connected by relationships. This way you will achive the least redundance of data and much less work.
But it has to be well thought and surely you will have to stat over from time to time.

[punkyard]

thanks again shalmaxb, it gives me a lot to think about yes, i truly need to understand the logic

[shalmaxb]

Hi, ok, I understand better now. As you state in the comment above, it seems a lot easier, because you won`t have complicated user roles.

1. The musicians should be users with the right to post venues. You can define that in roles. Don`t foget to mark the necessary fields as required, so that nobody can save a record, that is not complete.

2. You may think about, if only registered users may read the index or if you open it to musicians, who are not registered. If you would like to have that, you may create a user typ guest, with only read rights. Understand, that espoCRM is not an open "Website", so without regarding te role, it will always be necessary to login and for that be registered. Either as Musician or Guest. My opinion: I would not do that, I would give access only to musicians, no guests.

3. Your entity venues will be the main entity, which you may fill with as many records as you want. For this entity you have to think, which fields are important and which relationships to other entities you will need. You could have a relationship to users there, so that in a venue a field could display, which user contributed the venue. In the user the other way round, you could see all venues, that this user contributed.
I would start with the venue and the ideas will come working with it.

4. You will have to think about the user`s entity as well, which field you will need and so on.

But it is not too complicated.

[punkyard]

Sweet! that's moving forward! So it's going the direction I was imagining. I not sure about all the links yet, coz i'm not sure i'm getting the whole logic yet ^^
So the next part is to have a personnal area in which recording personnal info about the company behind the Stage.

Each artist would be able to create an account linked to a Stage, in which he'll write down his personal contacts and info about the stage.
Then I guess, it would work the same way between the artist/stage and the account/stage, right?

[punkyard]

on step forward! I have created a relationship between Stages and Accounts, so when an Artist creates a new Stage he can link it to an Account (read/write by his team)
in the layout, ACCOUNT MUST APPEAR IN THE BOTTOM PANEL .. not in 'detail' .. took me a while to figure that out ^^ then it made a whole difference!

could you give me a lead on what to do to add other fields manually please? (links, terms to look for in the forum?)

[shalmaxb]

Any entity, that is activated in espoCRM appears automatically in the folder custom/Espo/Custom/Resources/metadata/entityDefs/name of the entity, even those, which are part of espoCRM by default (like users e.g.). The reason for this is, that you may change these entities, by adding new fields, formulas and so on. All inside the custom folder will be update safe, what means, that any update of the core system would not affect the customized entities. Your work is protected in the custom folder.
Own, new entities will appear also in the custom folder.

Well, then you may change anything in the entity "users" and that will be saved in the respective custom entity "users".

For new fields you go to administrator -> entity manager -> entity to customize -> fields and klick in the upper left on "new field". Choose the desired field type, give it a name in the first input box as you want to name your field, e.g. "First Field". In the second input box, this name will be copied and in the first field the name wil be automatically adapted to the name convention of espoCRM, in this case firstField. (By the way this is called "camel case", because it starts with a small letter, has no spaces and the next word starts with a big letter, letting associate the appearance like the humps of a camel).
In the field configuration are more things to configure, depending on the field type. Most of it is self-explanatory.

Be aware, that you my change everything after the field has been created, except the name (first input box). This name goes to the database. If you want to change this, you will have to remove the field completely and start again to create it.

When the field is ready, you need to make it appear in your list or detail views, in the sidebar or wherever it is possible. For that you choose layout manager of that entity and pull the newly created field to a position in your layout. There you can add new empty placeholders for fields, can change the range of fields per line (1 to 4) and even create new panels for field placeholders. The panels you can give another name, appearance (color of header bar, or none) and make the panel show up conditional.

I will not describe everything, what is possible, play around a bit and you will see, how powerful all this is, without having to code.

[punkyard]

you mean you have purchased this software of eblasoft ?

[shalmaxb]

yes, and never regret

[esforim]

I think I already gave you my advertisement post, it contain thread that I find interesting or it have solution to that question. Consider going to them as shalmaxb said, the search is a hit and miss.