Symphony.

I know Nick Dunn has an Increment Field, but I don’t think it will do what I’m hoping for.

Basically I’m looking for a way to add an entry to a section via the frontend and will auto increment a particular field.

The field would have a default value (configurable, but numeric, ie. 500, 10000) and every time a new entry is created via the frontend, it would be incremented by 1 (or a value that you can define when creating the section).

Has this already been done?

Have a look at Nick’s Order Entries extension. It’s not exactly what you’re describing, but it’s pretty close.

Increment Field should do what you want with the exception of configuring the start value.

Maybe I missed something…

AFAIK, the numbers in an Increment Number Field are independent of other entries in that section, but rather are incremented each time that entry is called via DS… I thought brendo was asking for a field whose numerical value is incremented for each new entry in the section. Is that not right?

Correct czheng, it needs to increment every time a new entry is created via the frontend, not when the entry is called via a DS.

I already use the Order Entries field so can’t believe I didn’t think of that.

I might have a go at extending it a little bit to add the start value and an incremental value.

I completely misread your original post — yes, Order Entries sounds more like what you’re after. A quick workaround for the default number would be to enter a dummy entry with that value (e.g. 500). Subsequent entries will increment on top of that.

Hmm actually not sure Order Entries will do it. Numbers don’t increment when submitting through a frontend event.

Hmm, another extension to add to the ‘when there’s time’ list.

You could hard-code the logic into your event with SQL lookups.

You could hard-code the logic into your event with SQL lookups.

Thats what I thought once too. But then I remembered: There is no documentation on such things. Then I stopped working on that project.

To be honest, it’s getting a bit annoying lately. There is no information from the dev team (besides “yeah, we’re planning on doing that soon!”), still no documentation (even the documentation-threads are ignored) and no consistent API to work with…

yeah, we’re planning on doing that soon!

I’ll speak on behalf of Craig and say that things are happening.

But then I remembered: There is no documentation on such things. Then I stopped working on that project.

I don’t think any documentation is going to document how to do such things — any custom development is going to take some intuition and trial and error. You can get at the Database object through Frontend::instance()->Database->query(...) from which you can execute queries.

To be honest, it’s getting a bit annoying lately. There is no information from the dev team (besides “yeah, we’re planning on doing that soon!”), still no documentation (even the documentation-threads are ignored) and no consistent API to work with…

Craig has been working everyday the day he joined our team on the things discussed here and here.

It’s a big undertaking. Planning on the structure and flow of the documentation and implementing a system to support this, all takes time.

I don’t think any documentation is going to document how to do such things — any custom development is going to take some intuition and trial and error.

This might be true for developing extension. It should not be the case when creating custom events.

It’s a big undertaking. Planning on the structure and flow of the documentation and implementing a system to support this, all takes time.

Why don’t you guys include the community in your decision making? That’d kill two birds with one stone: Make it easier for you (or at least get another opinion when unsure) and show us what’s coming next.

Last post on the documentation topic here, since it’s going off-topic.

Why don’t you guys include the community in your decision making? That’d kill two birds with one stone: Make it easier for you (or at least get another opinion when unsure) and show us what’s coming next.

Craig asked, “give us your use cases. When will you need to consult the docs? What will you be looking for?”.

So far only one member has contributed. The “What you can expect to see” section show’s an accurate list of what is coming next.

The field would have a default value (configurable, but numeric, ie. 500, 10000) and every time a new entry is created via the frontend, it would be incremented by 1 (or a value that you can define when creating the section).

Any solutions come from this thread? About to work on one if not.

No Lewis, I don’t believe so, I managed to get away from the problem by just using the default system:id for each entry.

If you do work on the extension, I’d be excited to see the results.

It’d be nice if it had a configurable start value and increment.

I wonder if the field should be editable as well, or if it’s just static?

Well, I’m working on then. But what looked simple as getting complex for me. I need a unique field across multiple sections. So, if you have any ideas I appreciate it.

It looks like I am going to try and create a unique field that has the option of being unique across multiple sections.

It looks like I need to mirror the entry IDs.

My problem: I need to mirror IDs from an access database. The access database views members and children as one and the same; unique IDs. The website I created has children as a parent to a member. Thus, I need to assign and continue to assign unique IDs to members and children sections from the same incrementing number.

This is a real need, and I’m sticking with Symphony, so if anyone has any input that I can put into action, I appreciate it.

How about a separate table for the increment_field that has two fields, an increment auto_increment and then just linked-entry-id int.

The increment would be the field’s value, and the linked-entry-id would be the related entry id.

That would ensure uniqueness across sections, but it would make it hard (maybe impossible?) to do custom incrementing.

I just thought of a simple solution that should accomplish what I need. I’m going to build a field that mirrors the entry ID.

• It will automatically increment.
• Automatically increment across sections without conflict.

Does anyone see a downside to this solution?

If it’s a complete mirror of the system:id, then why not use that?