[spandit]

Wonder if setlists could have a date field that you can sort by? I have multiple gigs coming up and would be useful to know in what order they're coming in. My workaround is to add the date into the title but if I put it at the start then I can't sort alphabetically and vice versa.

[BRX]

They have. Just change the sort field (at the top rightish) to sort: date created or sort: date modified

[spandit]

They have. Just change the sort field (at the top rightish) to sort: date created or sort: date modified

Can I set the date of the gig, though? That's what I'm after...

[McAroni]

They have. Just change the sort field (at the top rightish) to sort: date created or sort: date modified

Can I set the date of the gig, though? That's what I'm after...

You could include the date of the gig in the setlist name. Date_Name of setlist...

[spandit]

You could include the date of the gig in the setlist name. Date_Name of setlist...

I mentioned this in my initial post - that takes away the ability to sort alphabetically

[itsme]

@BRX: I assume the question was not about the date when the setlist has been created or modified but about the event for that the setlist was meant to be used

@spandit: for my needs it is sufficient to use a decent naming convention
   
FB is the abbreviation for one of my bands, they are different enough that each letter in the alfabet list at the right shows the setlists for just one single band
yyyy-mm-dd makes sure that alfabetic sorting sorts by date
sort mode is set to A-Z descending so that current gigs are shown at the top. Thus I can keep historic setlists for reference.
I used date first and band name second in the beginning but decided to change that a while ago

@Mike: it would be useful if groups had some properties. E.g. a user specific nameable custom field for setlists could be used by spandit for the event date, custom fields for albums could contain publisher, ISBN or layout, custom fields for composers could be used for the day of death (which is relevant for European copyright) and so on. There are several requests in the forum that could conveniently be solved with user specific attributes for groups.

[McAroni]

You could include the date of the gig in the setlist name. Date_Name of setlist...

I mentioned this in my initial post - that takes away the ability to sort alphabetically

Sorry missed that...

[Geoff Bacon]

I name my setlists in a similar manner to itsme i.e. "venue yyyy-mm-dd"

Assuming you have only a small number of imminent gigs, put one or more spaces at the start of the setlist name - they will then appear at the top of the setlists page in a # section. 
After the performance, use the three vertical dots and rename the setlist without the leading spaces (assuming you want to keep the old list for reference).

If you have lots of imminent gigs, you could put the date in more than once  e.g. "2023-05-27 Venue 2023-05-27". After the performance, remove the leading date from the setlist name. This will display your future setlists with the most imminent at the top and, after the gig, sort them in date order according to the venue.

Geoff

[Zubersoft]

itsme - I can certainly consider supporting additional fields for groups, although then I'll need some kind of UI to edit/manage those fields. I'll also need to add additional sorting options if those fields are meant to be used for sorting. Also, in terms of how the fields should be displayed, I would either only display them while sorting on those fields, or I'd have to add another formatting type option to control the formatting so that users can decide if the field should be shown with the group name/title. Or I'd have to support displaying those fields below the group name as a caption. So this could potentially add a lot of work with all of the additional UIs and modifications to existing UIs to support them (as well as all the database changes). So it would definitely help to have a sense of exactly what would be needed to solve the requirements to limit the work to only what is really necessary and/or useful.

Thanks,
Mike

[itsme]

In fact, there would be a number of things to do.
Database changes might fit into the upcoming changes for song versioning.
A "group editor" could be similar to the "fields" tab of the existing song editor.
Configuring how groups are displayed on the respective groups tab could be done in a "group title formatting" similar to the existing song title formatting.
Exporting a group list would also be required.
Here's another request that could be conveniently resolved with group properties:
https://zubersoft.com/mobilesheets/forum...-9331.html

Where's my idea coming from? Currently I maintain a separate database to handle my collection of fakebooks. That database needs a rework and I'm thinking about what would be required to move everything into MobileSheets. Another option could be linking an external database to the data in the MobileSheets database.

If it's realistic that something like this will be implemented we should open a separate thread in the forum.

[BRX]

I'm sharing the interest of itsme. I myself have a big external database of my fakebooks etc. as well (well it's an Excel sheet)
with quite a bit more information and fields than MSP provides so far.

I used an extracted CSV for initial import into MSP. But to get changes into MSP or from data sharing between songs isn't really possible so far.
Some of my thoughts (like the master/slave suggestion) I've already mentioned in the versioning discussion (and I still wanted to elaborate
on that) and stem from thoughts on saving time and effort for data input and space in the database.

But if there are database changes, thoughts about more fields, managing/editing them with an UI, connections to CSV import and export in 
consideration, then I think it's well worth to make a separate topic