If we're creating a LayerBranch record, it's helpful to copy the
maintainer and dependency records in from master as they're usually
going to be the same; if they're not the user can always change them
afterwards.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
So it turns out that one or two layers have changed in structure between
branches, so we need to be able to specify this on a per-branch basis.
Good times...
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
The recently added global redirect was also redirecting incorrect URLs
within the application to the front page rather than showing 404, which
is not desirable.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
When clicking on an activation link, after verification,
the registration application tries to show
the activation_complete page. The template was missing,
so I added a basic skeleton.
Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com>
Modified the email body to break the blocktrans
into two separate blocks, and not include the
url block inside the blocktrans block.
Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com>
It's bad form to show the user a Page Not Found on
the first site open, so we redirect to the default
application.
Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com>
This enables sorting the branch drop-down in a configurable manner (e.g.
so that you can have them in order from newest to oldest).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Give the user a friendly introduction instead of plunging them straight
into the layers list. (Of course if people want to link directly to the
layers list they still can.)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
This cuts out a lot of the elements that aren't needed for the review
list, shows fields in a more suitable way for review purposes than the
standard detail (and includes some fields that don't currently get shown
on the standard detail e.g. layer type and short description).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Newly submitted layers don't have anything other than a master branch,
so they won't display properly unless we have master selected; so just
add a parameter to submission email and review URLs to ensure that is
the case.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Don't assume the current directory contains our conf/local.conf,
explicitly use the directory above where the script is located.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
This means there is only one place to set the base title instead of
needing to change it in every template.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
The simple views for about and the submit thanks pages don't need
special views, so the standard TemplateView can be used.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Add a badge next to the Review link (when shown for users with the
publish permission) on all pages showing how many layers need to be
reviewed, if any.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
This means the usage URL can point to a file whose contents may be
different per branch (e.g. a README file).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Change the data structure to support multiple branches. At the top level
there is a set list of Branch objects, and then a LayerBranch object
between each layer and the maintainers, dependencies, recipes and
machines, so that the set of each can be different per branch. The
branch is a session option, and can be selected via a drop-down that is
shown for all pages.
Additionally, with this change we avoid the need to run the update
script within a build environment set up with oe-init-build-env - since
we need a specific version of BitBake per branch we now use our own copy
of BitBake which is fetched by the script itself. The update script will
need to be called multiple times however - once per branch.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
This should prevent spamming even though this is less likely with this
kind of site.
The CAPTCHA does not show when editing, only submitting, and is also not
shown for authenticated users.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
* Don't specify action on form - this is best practice and avoids the
need to have separate form tags for submit and edit
* Add a short introduction to the submit form
* Focus first field on load only if first field is empty (avoids doing
this focusing on the edit form which is not really useful).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Hide all empty maintainer forms and have a button to "add" another
maintainer which just uses jQuery to show the next hidden form. Up to
10 maintainers can be added which should be more than enough.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If we get bogus or duplicate entries we'll want the ability to delete
them easily before publishing (without needing to have access to the
admin interface), so add this ability. Being able to delete a published
layer might be a bit dangerous and is less likely to be needed so that
is disallowed for now.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
This allows adding an important notice to a layer e.g. "this layer is
deprecated, please use layer xyz instead". Only one layer note can be
added through the interface although the data structures allow multiple,
so notes may be added programmatically without disturbing user-added
ones.
With this change we also add a get_absolute_url() function to the
LayerItem model and change the calls to reverse() for layers to use it.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If editing rather than submitting we want users to be able to make an
existing maintainer inactive.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Show "unpublished" rather than "new" in dependencies list in submit
form, and mention publishing as the operation in the "thanks for
submitting" page.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
* Add a label making it clear the layer is unpublished
* Hide recipes list header since there should never be any recipes (as
the update script doesn't process unpublished layers)
* Add test links for base URLs
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Allow users with publish permission to edit any layer, and users with
the same email address as one of the maintainers of a layer to edit that
layer.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Show button only if user has appropriate permission, and remove the
duplicate button at the end of the page as it's unlikely to be useful.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
